További Infó cikkek
A fejlesztő eszközök tulajdonképpen a szoftverfejlesztés "esztergapadjai". A hasonlat azonban erősen sántít. A legkomolyabb probléma a hasonlattal az, hogy a fejlesztő eszközök tulajdonképpen modelleznek is. Modellezik a számítógép működését és/vagy a megvalósítandó problémát. Folyamatmodellezés
Végignézve a programnyelvek fejlődését, jól nyomonkövethető, hogy míg kezdetben elsősorban a gépek működését modellezték (lásd alacsony szintű programnyelvek), addig mostanra a folyamatokét (OO eszközök) próbálják.
Az 1990-es évek közepétől az objektum orientált fejlesztő eszközök és megoldások kezdtek tömeges méretekben elterjedni. Ennek az volt az oka, hogy a programok soha nem látott mértékben váltak egyre bonyolultabbá. Ezeknek az eszközöknek a karbantartása bizony egyre nehezebbé vált. Sőt a legbosszantóbb az volt, hogy bizonyos programrészeket kis módosításokkal újra és újra meg kellett írni.
Az objektum orientáltságra való áttérés egyfajta paradigmaváltásnak is tekinthető a számítástechnikában.
A gépközpontúság helyett egy ettől elvontabb objektumközpontúság kezdett elterjedni, bár az előbbi hatása még mindig erőteljesen érvényesül az adatbázis-kezelés kapcsán. Jobban dokumentált
A fejlesztő eszközöknek kezdetben az egyedüli célja a kód előállítása volt. Ez ügyben is nagyot változott a világ. Ma már minden magára valamit is adó fejlesztőeszköz rendelkezik olyan képességekkel, melyek a kód jobb áttekinthetőségét, dokumentálását szolgálják, sőt egyre több úgynevezett CASE eszköz is hozzáférhető, mely a szoftver életciklusának több lépésében is segítséget nyújthat. Létező komponenst ne hozz létre
Az objektumorientáltság komoly segítséget nyújthat bizonyos alapproblémák szabványos megoldására. Az alapkoncepció szerint soha ne kezdjünk bele egy komponens megírásába, míg meg nem győződtünk róla, hogy nem létezik már olyan. Ha mindenki betartaná ezt a szabályt, és a komponensek működésében tapasztalt hibákról szóló visszajelzések eljutnának a fejlesztőkhöz, hogy tökéletesíthessék terméküket, az újabbnál újabb szoftverek egyre jobb minőségűek, és egyre hibátlanabbá válnának.
Sajnos a gyakorlatban ez csak részben valósul meg, hiszen az információáramlás egyik irányba sem működik igazán jól. A felhasználók nem kapnak elég információt a komponensekről és azok működéséről, a fejlesztők pedig nem jutnak visszajelzésekhez, de legalábbis nem tudnak idő hiányában mit kezdeni velük. Drágák
Akik már fejlesztettek ilyen módon szoftvert, azt is megjegyezhetik, hogy sajnos ezek a komponensek többnyire nem is ingyenesek, beépítésük sokszorosan megdrágítaná a termék előállítását.
A nagyobb megbízhatóság elérése érdekében jó lenne szabványosítani és ingyenesen hozzáférhetővé tenni az efféle komponenseket. Kicsit olyan módon, mint ahogyan bizonyos termékeket csak úgy lehet forgalomba hozni, ha azok fontosabb alkatrészeit előtte már bevizsgálták.
A sorozat következő és egyben befejező részében a szoftverfejlesztés folyamatáról lesz szó.