Az egyik (azóta csődbement) rózsadombi szoftverházunk neves rendszerszervezőjének félig tréfás megfogalmazása szerint Varga Géza ezzel a könyvével a szoftverfejlesztők árulójává vált.
A DQ szoftvergyártási technológia harmadik kiadásának címlapja
Ebből csak annyi igaz, hogy a "DQ" szoftvergyártási technológia kézikönyve olyan kulcsfontosságú információkat tartalmaz, amelyek ismeretében a szoftvert megrendelő - számítástechnikai szakismerettel általában nem rendelkező - döntéshozók eredményesebben képviselhetik a felhasználói érdekeket a szoftverfejlesztések során. Ezeknek a fejlesztéseknek a fele ma kudarcba fullad és ennek köszönhetően felhasználói körökben gyakran adnak hangot a szoftverfejlesztők szakmai és etikai színvonalával kapcsolatos fenntartásaiknak.
E fenntartások gyakran jogosak - a kudarcok bekövetkezéséért azonban nagyon sok esetben magukat a megrendelőket is súlyos felelősség terheli.
Tucatnyi szoftverház tevékenységét, több száz programfejlesztés tanulságait és az irodalom ajánlásait elemezve, Varga Géza - kálvinista paraszt őseihez méltóan - közérthető és gyakorlatias megoldást javasol. Ez az ajánlás fő célkitűzéseiben megegyezik a világ szoftveriparában teret hódító legmodernebb felismerések lényegével, de eszközeiben költségkímélő és egyaránt használható nagy- vagy kisgépes, kötegelt vagy valós idejű rendszerek fejlesztéséhez is. A szerző - több mint két évtizedes programozói, szervezői és vezetői gyakorlata alapján - azt állítja, hogy a kudarcokat jórészt a fejlesztési technikák egyoldalú irányultsága okozza. Ezek a technikák a szerző szerint jók, de nem a legnagyobb veszélyhelyzetek elhárítására szolgáinak - ezért rengeteg kellemetlen mellékkörülmény jelentkezik. Gyakran előfordul például, hogy a szoftver nem oldja meg a felhasználó problémáit, bár a programozói tevékenység eredményét (önmagában vizsgálva) akár műremeknek is lehetne nyilvánítani - ha a felhasználó szempontjait figyelmen kívül hagyhatnánk.
Csak a fejlesztési folyamat szervezettebbé tételévei, a projektirányítás hatékonyságának növelésével, a tervezés és a szervezői tevékenység előtérbe állításával képzelhető el a helyzet javítása. A "DQ" szoftvergyártási technológia ennek a feladatnak egy lehetséges megoldását kínálja - egyaránt szolgálva ezzel a felhasználók és a fejlesztők érdekét is. Mivel a szoftverházak gyakorlott rendszerfejlesztőit hasonló gondolatok foglalkoztatják (nehéz több tucat programozó munkáját áttekinteni és irányítani), a kötet megismerése a számukra is hasznos lehet.
Az eddigi értékesítési adatok és a kötet kedvező szakmai visszhangja arra engednek következtetni, hogy a módszertan hiányt pótol.
A tartalomjegyzék részlete
TARTALOMJEGYZÉK
1. ELŐSZÓ
2. A SZOFTVER ÉLETCIKLUSA
2.1. Az előkészítés
2.2. A tervezés
2.3. A programozás
2.4. A próbaüzemeltetés
2.5. Az üzemeltetés
2.6. Rendszerkövetés, továbbfejlesztés
3. DOKUMENTUMOK ÉS DOKUMENTÁCIÓK
3.1. TMD táblázat
3.2. Téma irattár
3.3. Munkakísérő napló
3.4. Rendszerjavaslat
3.5. Nagyvonalú rendszerterv
3.6. Részletes rendszerterv
3.7. Programdokumentáció
3.8. Üzemeltetési dokumentáció
3.9. Felhasználói dokumentáció
3.10. Az üzemeltetés gyűjtői
4. ALKALMAZÁSI ÚTMUTATÓ
4.1. A technológia bevezetése és használata
4.2. Az információrendszerrel szemben támasztott követelmények
4.3. A fejlesztői munkastílus javasolt elvei
4.4. A programozói munkastílus javasolt elvei
4.5. A szerzői jogok
4.6. A szerződés
4.7. Átvilágítás
4.8. Helyzetfelmérés
4.9. Helyzetértékelés
4.10. Adatfolyamábra
4.11. Folyamatábra-készítés
4.12. Adatmodell
4.13. Tevékenység-, adat- és programstruktúra
4.14. Adatbiztonság
A kötet előszava
1. ELŐSZÓ
A kötet születéséről
Milliárdos nagyságrendű világbanki hitelből finanszírozott gyárrekonstrukció kellős közepébe csöppentünk bele néhány éve, szervezők és programozók. Legfontosabb feladatunk az új termelésirányító szoftver azon első moduljainak az üzembehelyezése volt, amelyeknek a gyárba érkező megrendeléseket kellett feldolgozniuk. Ezek üzembehelyezésére - hat osztály összehangolt erőfeszítésével - csak negyedévenként egyszer nyílt alkalom.
Amikor már a második kísérletünk sem sikerült, rá kellett döbbennünk, hogy a kudarc törvényszerűen be fog következni a harmadik negyedévben is, ha a munkában résztvevők feladatát nem határozzuk meg pontosan és ha nem tudjuk a tevékenységüket könnyen és gyorsan ellenőrizni. Amennyiben el akarjuk végezni a munkánkat, akkor át kell törni némelyik felhasználó ellenérdekeltségén és munkára kell kényszeríteni a számítóközpont üzemeltetési részlegének naplopóit. Ehhez azonban megfelelő eszközre volt szükségünk.
Megterveztük, majd kitöltöttük a 38-as típuslapot és egy - a végrehajtását elrendelő - igazgatói utasítás kíséretében átadtuk az érintetteknek. Hála a típuslapokon megszabott kényszerpályáknak, a harmadik kísérlet már sikeres volt: a rendszer feléledt és működni kezdett.
Hasonló történetek és tapasztalatok bújnak meg a kötet többi lapja mögött is, amelyekkel elsősorban a saját tevékenységünket szabályoztuk. Ez a szabályozás a napi fejlesztői munkafolyamat megfelelő mederben tartását, segítését és ellenőrzését tűzte ki célul - ezért a kötet inkább gyakorlati, mint elméleti irányultságú. Ennek is köszönhető a módszer gépfüggetlensége (kis- vagy nagygépes, kötegelt vagy valós idejű, egy- vagy többfelhasználós rendszerek egyaránt fejleszthetők vele), keret jellege (integrálható más fejlesztői módszerekkel is) valamint a sokoldalúsága (nem csak a fejlesztők munkaeszköze, hanem például a szoftvert megrendelő döntéshozóé is).
Közreadása segítse azok munkáját, akik hasonlóan nehéz helyzetekkel küzdenek.
Szükség van-e technológiára?
A számítástechnika - a szoftver jellegéből következően - veszélyes munkaterület. A szoftverfejlesztések és -alkalmazások gyakran szolgálnak kellemetlen meglepetésekkel:
- a szoftver nem készül el határidőre,
- a fejlesztés túllépi a költségkereteket,
- az elkészült rendszer nem azt csinálja, amit kellene,
- az üzemeltetést szándékos és nem szándékos (pl. a tapasztalatlanságból fakadó) cselekmények, meghibásodások és katasztrófák akadályozzák,
- a rendszerben rejlő számos hiba vagy a körülmények megváltozása is egyaránt veszteségek forrása lehet,
- csak komoly erőfeszítést igénylő teszteléssel állapítható meg a szoftver minősége, ezért az óvatlan megrendelő esetenként átveszi és kifizeti a félig kész, hibás rendszert is,
- a szoftver gyakran ellenáll a módosításnak és nehezen telepíthető át másik számítógépre.
A bekövetkező anyagi és erkölcsi károk igen komolyak lehetnek, fontos egyéni és közösségi célkitűzések meghiúsulását okozhatják. A fiaskók oka jórészt a munkában résztvevők (szoftverfejlesztők és felhasználók) közötti kommunikáció hiányosságaira vezethető vissza.
Nem alakult még ki egy olyan általánosan elfogadott, közös szakmai nyelv, amelyen minden résztvevő egyformán jól ki tudná fejezni a saját gondolatait és megértené a másikét.
Amíg például a családi házak építési terveit az építész, a kőműves és az építtető is egyaránt könnyen megérti, addig a számítástechnikai rendszertervek esetében ilyesmiről szó sincs.
A különbség a szoftver eltérő sajátosságaira vezethető vissza. A családi házak felépítését és mííködését kívül-belül egyaránt szemügyre lehet venni - a szoftver lényege azonban nem ismerhető meg ilyen egyszerűen. A szoftver túlságosan sok elemből épül fel, nagy a működési variációk száma, minden rendszer prototípus jellegű, a működésbe állítása pedig csak - az esetenként szintén bonyolult és változó - környezethez való illesztéssel lehetséges.
A fejlesztés kezdetén a rendszer - és így a fejlesztők - feladatát senki sem tudja pontosan megfogalmazni. Ennek a feladatnak a meghatározása a munka előrehaladtával egyre alaposabbá válik, de teljesen csak a munka végeredménye - a jól elkészített program forráslistája - fogja majd rögzíteni. Ebből az is következik, hogy a megkötött szerződések eleve magukban hordozzák a bukás lehetőségét vagy szükségszerűségét. Egy korábbi felmérés szerint a fejlesztések fele kudarcba is fullad, és csak minden negyedik felhasználó tartja eredményesnek külső fejlesztők alkalmazását.
Jellegéből fakadóan a szoftver készítése sem lehet egyszerű. A kockázati tényezők hatását csak egy - a feladat sajátosságaihoz alkalmazkodó iparszerű szoftvergyártási technológiával lehet csökkenteni. A feladat megfogalmazása, a tervezés, a megvalósítás és a felhasználás egyaránt körülte'intést igénylő, összetett feladat. Acél megfogalmazásától a sikeres üzemeltetésig csak a megfelelő eszközök, birtokában, a meghatározott lépéseket betartva lehet eljutni - ezért a szoftverrendszert szabályozott eljárás keretében szükséges létrehozni és működtetni.
A DQ szoftvergyártási technológia ennek a feladatnak a megoldásához kíván hozzájárulni.
Varga Géza számítástechnikai rendszerszervező
***
Jókai Mórral és Gárdonyi Gézával már nem beszélgethet; a fenti cikk szerzőjének azonban - egy ideig - még kérdéseket tehet fel, amikor az Őrség ben, a velemériCsinyálóház ban nyaral.
50% last minute kedvezmény jár e cikk olvasójának is!
***
Cserépmadár szállás (õrségi szálláshely, falusi turizmus)
Csinyálóház (õrségi szálláshely, falusi turizmus)
Õrségi látnivalók településenként
Õrségi látnivalók témánként
Veleméri képek
Apróhirdetés
Könyv
Õrség
A DQ szoftvergyártási technológia harmadik kiadásának címlapja
Ebből csak annyi igaz, hogy a "DQ" szoftvergyártási technológia kézikönyve olyan kulcsfontosságú információkat tartalmaz, amelyek ismeretében a szoftvert megrendelő - számítástechnikai szakismerettel általában nem rendelkező - döntéshozók eredményesebben képviselhetik a felhasználói érdekeket a szoftverfejlesztések során. Ezeknek a fejlesztéseknek a fele ma kudarcba fullad és ennek köszönhetően felhasználói körökben gyakran adnak hangot a szoftverfejlesztők szakmai és etikai színvonalával kapcsolatos fenntartásaiknak.
E fenntartások gyakran jogosak - a kudarcok bekövetkezéséért azonban nagyon sok esetben magukat a megrendelőket is súlyos felelősség terheli.
Tucatnyi szoftverház tevékenységét, több száz programfejlesztés tanulságait és az irodalom ajánlásait elemezve, Varga Géza - kálvinista paraszt őseihez méltóan - közérthető és gyakorlatias megoldást javasol. Ez az ajánlás fő célkitűzéseiben megegyezik a világ szoftveriparában teret hódító legmodernebb felismerések lényegével, de eszközeiben költségkímélő és egyaránt használható nagy- vagy kisgépes, kötegelt vagy valós idejű rendszerek fejlesztéséhez is. A szerző - több mint két évtizedes programozói, szervezői és vezetői gyakorlata alapján - azt állítja, hogy a kudarcokat jórészt a fejlesztési technikák egyoldalú irányultsága okozza. Ezek a technikák a szerző szerint jók, de nem a legnagyobb veszélyhelyzetek elhárítására szolgáinak - ezért rengeteg kellemetlen mellékkörülmény jelentkezik. Gyakran előfordul például, hogy a szoftver nem oldja meg a felhasználó problémáit, bár a programozói tevékenység eredményét (önmagában vizsgálva) akár műremeknek is lehetne nyilvánítani - ha a felhasználó szempontjait figyelmen kívül hagyhatnánk.
Csak a fejlesztési folyamat szervezettebbé tételévei, a projektirányítás hatékonyságának növelésével, a tervezés és a szervezői tevékenység előtérbe állításával képzelhető el a helyzet javítása. A "DQ" szoftvergyártási technológia ennek a feladatnak egy lehetséges megoldását kínálja - egyaránt szolgálva ezzel a felhasználók és a fejlesztők érdekét is. Mivel a szoftverházak gyakorlott rendszerfejlesztőit hasonló gondolatok foglalkoztatják (nehéz több tucat programozó munkáját áttekinteni és irányítani), a kötet megismerése a számukra is hasznos lehet.
Az eddigi értékesítési adatok és a kötet kedvező szakmai visszhangja arra engednek következtetni, hogy a módszertan hiányt pótol.
A tartalomjegyzék részlete
TARTALOMJEGYZÉK
1. ELŐSZÓ
2. A SZOFTVER ÉLETCIKLUSA
2.1. Az előkészítés
2.2. A tervezés
2.3. A programozás
2.4. A próbaüzemeltetés
2.5. Az üzemeltetés
2.6. Rendszerkövetés, továbbfejlesztés
3. DOKUMENTUMOK ÉS DOKUMENTÁCIÓK
3.1. TMD táblázat
3.2. Téma irattár
3.3. Munkakísérő napló
3.4. Rendszerjavaslat
3.5. Nagyvonalú rendszerterv
3.6. Részletes rendszerterv
3.7. Programdokumentáció
3.8. Üzemeltetési dokumentáció
3.9. Felhasználói dokumentáció
3.10. Az üzemeltetés gyűjtői
4. ALKALMAZÁSI ÚTMUTATÓ
4.1. A technológia bevezetése és használata
4.2. Az információrendszerrel szemben támasztott követelmények
4.3. A fejlesztői munkastílus javasolt elvei
4.4. A programozói munkastílus javasolt elvei
4.5. A szerzői jogok
4.6. A szerződés
4.7. Átvilágítás
4.8. Helyzetfelmérés
4.9. Helyzetértékelés
4.10. Adatfolyamábra
4.11. Folyamatábra-készítés
4.12. Adatmodell
4.13. Tevékenység-, adat- és programstruktúra
4.14. Adatbiztonság
A kötet előszava
1. ELŐSZÓ
A kötet születéséről
Milliárdos nagyságrendű világbanki hitelből finanszírozott gyárrekonstrukció kellős közepébe csöppentünk bele néhány éve, szervezők és programozók. Legfontosabb feladatunk az új termelésirányító szoftver azon első moduljainak az üzembehelyezése volt, amelyeknek a gyárba érkező megrendeléseket kellett feldolgozniuk. Ezek üzembehelyezésére - hat osztály összehangolt erőfeszítésével - csak negyedévenként egyszer nyílt alkalom.
Amikor már a második kísérletünk sem sikerült, rá kellett döbbennünk, hogy a kudarc törvényszerűen be fog következni a harmadik negyedévben is, ha a munkában résztvevők feladatát nem határozzuk meg pontosan és ha nem tudjuk a tevékenységüket könnyen és gyorsan ellenőrizni. Amennyiben el akarjuk végezni a munkánkat, akkor át kell törni némelyik felhasználó ellenérdekeltségén és munkára kell kényszeríteni a számítóközpont üzemeltetési részlegének naplopóit. Ehhez azonban megfelelő eszközre volt szükségünk.
Megterveztük, majd kitöltöttük a 38-as típuslapot és egy - a végrehajtását elrendelő - igazgatói utasítás kíséretében átadtuk az érintetteknek. Hála a típuslapokon megszabott kényszerpályáknak, a harmadik kísérlet már sikeres volt: a rendszer feléledt és működni kezdett.
Hasonló történetek és tapasztalatok bújnak meg a kötet többi lapja mögött is, amelyekkel elsősorban a saját tevékenységünket szabályoztuk. Ez a szabályozás a napi fejlesztői munkafolyamat megfelelő mederben tartását, segítését és ellenőrzését tűzte ki célul - ezért a kötet inkább gyakorlati, mint elméleti irányultságú. Ennek is köszönhető a módszer gépfüggetlensége (kis- vagy nagygépes, kötegelt vagy valós idejű, egy- vagy többfelhasználós rendszerek egyaránt fejleszthetők vele), keret jellege (integrálható más fejlesztői módszerekkel is) valamint a sokoldalúsága (nem csak a fejlesztők munkaeszköze, hanem például a szoftvert megrendelő döntéshozóé is).
Közreadása segítse azok munkáját, akik hasonlóan nehéz helyzetekkel küzdenek.
Szükség van-e technológiára?
A számítástechnika - a szoftver jellegéből következően - veszélyes munkaterület. A szoftverfejlesztések és -alkalmazások gyakran szolgálnak kellemetlen meglepetésekkel:
- a szoftver nem készül el határidőre,
- a fejlesztés túllépi a költségkereteket,
- az elkészült rendszer nem azt csinálja, amit kellene,
- az üzemeltetést szándékos és nem szándékos (pl. a tapasztalatlanságból fakadó) cselekmények, meghibásodások és katasztrófák akadályozzák,
- a rendszerben rejlő számos hiba vagy a körülmények megváltozása is egyaránt veszteségek forrása lehet,
- csak komoly erőfeszítést igénylő teszteléssel állapítható meg a szoftver minősége, ezért az óvatlan megrendelő esetenként átveszi és kifizeti a félig kész, hibás rendszert is,
- a szoftver gyakran ellenáll a módosításnak és nehezen telepíthető át másik számítógépre.
A bekövetkező anyagi és erkölcsi károk igen komolyak lehetnek, fontos egyéni és közösségi célkitűzések meghiúsulását okozhatják. A fiaskók oka jórészt a munkában résztvevők (szoftverfejlesztők és felhasználók) közötti kommunikáció hiányosságaira vezethető vissza.
Nem alakult még ki egy olyan általánosan elfogadott, közös szakmai nyelv, amelyen minden résztvevő egyformán jól ki tudná fejezni a saját gondolatait és megértené a másikét.
Amíg például a családi házak építési terveit az építész, a kőműves és az építtető is egyaránt könnyen megérti, addig a számítástechnikai rendszertervek esetében ilyesmiről szó sincs.
A különbség a szoftver eltérő sajátosságaira vezethető vissza. A családi házak felépítését és mííködését kívül-belül egyaránt szemügyre lehet venni - a szoftver lényege azonban nem ismerhető meg ilyen egyszerűen. A szoftver túlságosan sok elemből épül fel, nagy a működési variációk száma, minden rendszer prototípus jellegű, a működésbe állítása pedig csak - az esetenként szintén bonyolult és változó - környezethez való illesztéssel lehetséges.
A fejlesztés kezdetén a rendszer - és így a fejlesztők - feladatát senki sem tudja pontosan megfogalmazni. Ennek a feladatnak a meghatározása a munka előrehaladtával egyre alaposabbá válik, de teljesen csak a munka végeredménye - a jól elkészített program forráslistája - fogja majd rögzíteni. Ebből az is következik, hogy a megkötött szerződések eleve magukban hordozzák a bukás lehetőségét vagy szükségszerűségét. Egy korábbi felmérés szerint a fejlesztések fele kudarcba is fullad, és csak minden negyedik felhasználó tartja eredményesnek külső fejlesztők alkalmazását.
Jellegéből fakadóan a szoftver készítése sem lehet egyszerű. A kockázati tényezők hatását csak egy - a feladat sajátosságaihoz alkalmazkodó iparszerű szoftvergyártási technológiával lehet csökkenteni. A feladat megfogalmazása, a tervezés, a megvalósítás és a felhasználás egyaránt körülte'intést igénylő, összetett feladat. Acél megfogalmazásától a sikeres üzemeltetésig csak a megfelelő eszközök, birtokában, a meghatározott lépéseket betartva lehet eljutni - ezért a szoftverrendszert szabályozott eljárás keretében szükséges létrehozni és működtetni.
A DQ szoftvergyártási technológia ennek a feladatnak a megoldásához kíván hozzájárulni.
Varga Géza számítástechnikai rendszerszervező
***
Jókai Mórral és Gárdonyi Gézával már nem beszélgethet; a fenti cikk szerzőjének azonban - egy ideig - még kérdéseket tehet fel, amikor az Őrség ben, a velemériCsinyálóház ban nyaral.
50% last minute kedvezmény jár e cikk olvasójának is!
Cserépmadár szállás (õrségi szálláshely, falusi turizmus)
Õrségi látnivalók településenként
Õrségi látnivalók témánként
Veleméri képek
Apróhirdetés
Könyv
Õrség
