A programozástól a rendszerfejlesztésig A kicsiben jól működő elveket magasabb szintre emelik.

Strukturált szemlélet: jól kidolgozott mind programozásra, mind a programtervezésre (Jackson- módszer, Wairner módszer), mind rendszertervezésre (SSADM).

Az objektumorientált szemlélet a programozásban megkerülhetetlen (szinte minden 4GL eszköz az oo szemléletre épít), vannak jól kidolgozott program tervezési módszerek (OMT, UML, Design patterns), s az oo szemlélet mostanság kezdi kiterjedni a szoftver fejlesztés módszertanok területére (Egységesített Eljárás). Jelenleg még valóban oo szemléletű rendszerszervezési módszertan nincsen.

Adatbáziskezelés Bár az adatbázis-kezelés logikailag nagyjából a programozással egy absztrakciós szinten van, de mind a mai az adatbázis-kezelésben szinte egyeduralkodó a strukturált (relációs; Codd -féle) szemlélet. Bár kísérletek meglehetősen hosszú ideje folynak oo adatbázis-kezelőkkel, de valóban használható, valóban oo szemléletű adatbázis-kezelő nincsen piaci forgalomban.

Léteznek is kísérletek, kutatások az oo szemlélet meghaladására, talán a két legígéretesebb irányzat a minták alkalmazása (patterns), illetve az extrém programozásnak nevezett szemlélet. Közös azonban ezekben a kísérletekben, hogy nem elvetik, hanem továbbfejlesztik az oo szemléletet, és megvalósításukat tekintve is jellemzően oo eszközökre támaszkodnak.

Nevezetes szoftverfejlesztési modellek A fejlesztési modellek a fejlesztési folyamat átfogó, koncepcionális modelljét írják le. Ritkán jelennek meg tiszta, ideális formában, sokkal inkább a fejlesztési folyamat egyfajta logikai absztrakciója.

Vízesés modell A szoftver fejlesztés első publikált modellje (1970), ami viszonylag stabil körülmények között mind a mai napig jól működik. A fejlesztési folyamatot fázisokra bontja, a fázisok szigorúan egymás után következnek, minden egyes fázisra jellemzőek azok a dokumentumokat, amiket el kell fogadni („alá kell írni”) a továbblépéshez.

A gyakorlatban a fázisok többé-kevésbé átfedhetik egymást. Az egyes fázisok végrehajtása iteratív tevékenység. A dokumentumok előállításának, jóváhagyásának a költségei miatt elfogadott gyakorlat, hogy egy-egy fázist már néhány iteráció után befagyasztanak, a problémák megoldását lehagyják, kikerülik avagy későbbre halasztják. Így a rendszer már az átadás pillanatában sem felel meg az éppen aktuális követelményeknek. Ugyanakkor a rejtett, lappangó felhasználói igények, tapasztalatok csak nagyon későn, a rendszer működtetése során kerülnek felszínre. Vízesés modell

Követelmények meghatározása Elemzés Tervezés Implementáció és egységtesztelés Integráció és rendszerteszt Működtetés és Karbantartás Akkor alkalmazható hatékonyan, ha a követelmények jól definiáltak és stabilak. Vízesés modell

Evolúciós fejlesztés Alapötlete, hogy a kezdeti követelmények alapján lehetőleg olcsón és gyorsan fejlesszünk ki egy termékverziót. Ennek a terméknek a használata során összegyűlt tapasztalatokat építsük be egy újabb termék verzióba. Ezt a folyamatot mindaddig ismételjük, amíg el nem érjük a kívánalmaknak már megfelelő rendszert. Sokkal inkább lehetővé teszi a párhuzamosságot és sokkal gyorsabban csatolja vissza a fejlesztési folyamatba a menet közben felmerülő felhasználói igényeket.

Az evolúciós fejlesztés típusai ● FELTÁRÓ FEJLESZTÉS A fejlesztés célja, hogy a megrendelővel szorosan együttműködve feltárjuk a valós igényeket és kifejlesszük a végleges rendszert. A rendszer fejlesztését a már ismert részekkel kell kezdeni, s újabb és újabb elemek hozzáadásával jutunk el a végtermékig.

● ELDOBHATÓ PROTOTÍPUS KÉSZÍTÉSE Az evolúciós fejlesztés célja a követelmények mennél pontosabb feltárása. A prototípus próbálgatásos módszerrel közelíti meg a követelményeket, elsősorban az ismeretlen követelmények feltárására koncentrál. A sokszori átdolgozás miatt törvényszerű, hogy a belső struktúra nehezen átláthatóvá válik. Az eldobható prototípust végtermékké minősíteni, avagy az eldobható prototípus kódját közvetlenül felhasználni a végtermékben súlyos szakmai hiba. Hátránya ennek a modellnek, hogy ● A fejlesztési folyamat előrehaladása nem látható, nem mérhető. Ez gyakran proektmenedzselési gondokhoz vezet. ● Rosszul strukturált, nehezen továbbfejleszthető terméket eredményez. Az evolúciós fejlesztés típusai

Inkrementális fejlesztés Hibrid megközelítési mód, a vízesés illetve az evolúciós modell előnyeit ötvözi. A fejlesztés indításakor a megrendelő vázlatosan közli a követelményeit, illetve meghatározzák, mely követelmények a fontosabbak, s melyek kevésbé fontosak. Az első inkremens kifejlesztésével párhuzamosan folyhat a további inkremensek specifikálása, tervezése. Amikor egy inkremens elkészül, azt integrálni kell a már elkészült rendszerbe, s utána azt a felhasználó használatba is veheti. Az üzemeltetéssel kapcsolatos tapasztalatok visszacsatolhatóak a további inkremensek tervezésébe.

Az inkrementális fejlesztés előnye, hogy A megrendelőnek nem kell megvárnia a teljes rendszer elkészültét, hanem már az első inkremens átadása után használhatja a rendszer legfontosabb szolgáltatásait. A korábban kifejlesztett inkremensek tekinthetők prototípusnak, a használatuk során szerzett tapasztalatok beépíthetőek a fejlesztés folyamatába. Csökkenti a kockázatot. Az egyes inkremensekben ugyan lehetnek hibák, azonban valószínű, hogy ezek az egész projekt kudarcát okozzák. A magas prioritású inkremenseket szállítjuk le először, így azok lesznek a legjobban kitesztelve. Inkrementális fejlesztés

Spirális fejlesztés Az iteratív megközelítés során a fejlesztés mintegy spirál vonalban halad előre, a felhasználó, avagy a megrendelő rendszeresen megkapja az újabb és újabb futtatható programverziókat.

Újrafelhasználás-orientált fejlesztés Jelenleg még viszonylag szűkebb körben alkalmazott fejlesztési megközelítés, azonban feltehetőleg a közeli jövőben egyre többen fogják tudatosan ezt a megközelítést választani. A fejlesztési folyamatot a meglévő komponensek újrafelhasználása határozza meg. Jelentős méretű komponens könyvtárak létét tételezi fel. Ebben a megközelítésben a komponens nem csak a 4GL eszközök szokásos, finom szemcsézettségű komponensei (nyomógombok, címkék, stb.), hanem nagyméretű, üzleti komponensek (főkönyv, kezelő alrendszer, stb.) is lehetnek, gyakran önálló létjogosultsággal rendelkező alrendszerek (pl.: szövegszerkesztő, számolótábla, stb.)

Formális rendszerfejlesztés A fejlesztés kiinduló pontja egy matematikailag egzakt rendszerdefiníció. Ezt a formális definíciót matematikailag meghatározott, ellenőrzött transzformációkkal alakítják át működő rendszerré. A matematikailag egzakt programhelyesség-bizonyítás hihetetlenül drága. Ezzel szemben a formális fejlesztés során mindig matematikailag egzakt lépések történnek, így a fejlesztés végén az elkészült termék törvényszerűen megfelel a specifikációnak. Ez a fejlesztési modell biztonság-, avagy védelem-kritikus rendszerek fejlesztése során használatos, egyéb fejlesztésekben alig használják.