További Infó cikkek
Az idő pénz
Az informatikai termékeknél sajnos ez nem egészen így történik. A megrendelők legtöbbször nem bíbelődnek túl sokat az elvárásaik pontos rögzítésével, nem kíváncsiak a tervekre. Sokkal tömörebben és egyszerűbben szokták kifejezni a szoftver iránti követelményeiket: "Két hét alatt legyen kész!".
A tervezésen spórolnak
Eddigi tapasztalataim alapján a fejlesztési időket minimum kétharmadával rövidebbre határozzák meg, mint ahogyan annak lennie kellene. Ez persze a fejlesztőket arra sarkalja, hogy elhagyják a felmérési, specifikálási és tervezési fázisokat, és helyette azonnal a fejlesztésbe fogjanak. A gond csak az, hogy a fejlesztési idő makacs dolog, ráadásul többnyire alsó korlátként működik. Ha egy fejlesztést a fázisok elhagyásával rövidebb idő alatt kívánunk átadni, és tegyük fel ez sikerül is, az eredetileg szükséges időt meghaladó időtartamban kell hibajavítással, pótlólagos fejlesztésekkel foglalkoznunk.
A hat hónapos szabály
Ha fejlesztéssel foglalkozik az igen tisztelt olvasó, bizonyára ismeri a hat hónapos szabályt. Nincsen ennél rövidebb ideig tartó fejlesztés, akkor sincsen, ha van. Legfeljebb az egyes fázisok hosszának aránya változik meg egymáshoz képest.
Eddigi életem során megszámlálhatatlanul sokszor találkoztam "melldöngetős" két hetes, vagy egy hónapos fejlesztéssel, amit még a következő év végére sem sikerült befejezni.
Harminc napra vállalják
Szoftverfejlesztő cégek erre - tegyük hozzá jogosan - azt állíthatják, hogy ha a megrendelő 1 hónapot ad rá, és mi korrekt módon fél évre vállalnánk fel a munkát, más fejlesztő után nézne.
Ez sajnos igaz, ennek a megváltozásához azonban arra van szükség, hogy szemléletváltozás következzen be a szoftverek, mint ipari termékek megítélésében.
Ez utóbbi meghatározás úgy érzem, kulcsszava is a megoldásnak. Sokan talán úgy gondolják, hogy mivel meg kell írni a programot, valójában egy egzotikus nyelven megírt szöveg elkészítéséről van szó. Pedig nem. Egy ipari termékről, melynek belső felépítése alkalmasint legalább olyan bonyolult szerkezetű lehet, mint mondjuk egy gépkocsié, vagy egy híradástechnikai berendezésé. Azt pedig alaposan meg kell tervezni.
A tervezés során azonban bizonyos dolgokat, folyamatokat, alkatrészeket, részegységeket, stb meg kell tudni jeleníteni. Egy gép, vagy épület esetén ezek közvetlenül egy-egy valóságos tárgy leképezései. Csak kisfokú absztrakcióra van szükség.
Rendszerterv
A szoftverek esetében gyökeresen más a helyzet, hiszen többnyire bizonyos folyamatok támogatására készülnek. Ahhoz pedig, hogy ez megfelelőképpen történhessen elsőként a támogatandó rendszert kell feltérképezni.
Ez azonban így még semmi. Valójában a szoftver elkészültével ez a rendszer meg is fog változni, tehát nekünk a valóság helyett egy modellt kell modelleznünk, és ennek alapján kell terveznünk. A modellezés során persze a megvalósításban résztvevő eszköz képességeit és korlátait is figyelembe kell vennünk.
A tervezés tehát nem önmagában való folyamat. A rendszer megértése után, vagy azzal párhuzamosan történhet csak. Ahogyan nem állítható össze megvalósítható terv a feladat részletes megismerése nélkül, úgy az sem képzelhető el, hogy egy összetettebb rendszert hiba nélkül ki lehessen alakítani megfelelő elképzelések (terv) nélkül.
Megjegyzem persze, hogy a szoftverek fejlesztése egy kissé el is tér mondjuk az építkezések menetétől. Hiszen míg egy épület megismerhető, és át is alakítható az eredeti terv ismerete nélkül is, addig ez egy szoftver esetén szinte elképzelhetetlen.
Közös nyelv
Ki ne hallott volna már olyan programról, mely ugyan tökéletesen működött, de a változtatási igények miatt mégis le kellett cserélni, hiszen elment a cégtől az eredeti fejlesztője.
A tervnek tehát egyben a közös nyelv szerepét is be kell töltenie a fejlesztők között. Sajnos ez jelen pillanatban igen csekély mértékben mondható el, hiszen a fejlesztő eszközök, és fejlesztési módszerek miatt a tervezési technikák sem egyformák.
A következő részben a fejlesztőeszközökről és az objektum orientáltságról lesz szó.