Informatikai projektek Mirt klnleges a szoftvermenedzsment A termk

Informatikai projektek Miért különleges a szoftvermenedzsment? A termék nem materiális. A termék különlegesen flexibilis. A szoftvermérnökség nem rendelkezik más mérnöki tudományokhoz hasonló szilárd alapokkal (pl. gépész , villamosmérnök). A szoftverfejlesztési eljárás nem teljesen szabványosított. Az informatikai projektek sokszereplősek, sok az érintett (megrendelő, felhasználó, üzemeltető, stb. ). Magasan kvalifikált emberek dolgoznak együtt, akik ennek megfelelő kezelést igényelnek. Az informatikai projektek általában nem hatalmas méretűek

Informatikai projektek fajtái (szoftver ) Termékfejlesztési projekt (egyedi) Alkalmazásfejlesztési projekt Alkalmazásintegrációs projekt rendszerintegrálási projekt bevezetési projekt infrastruktúrafejlesztési projekt tanulmánykészítési projekt (felmérés, előkészítés, bevizsgálás) tesztelési projekt

Milyen a tökéletes szoftver projekt? A megrendelő elégedett, mert a termék pontosan alkalmas a megadott célra. • A felhasználók jól tudják használni a terméket, ettől munkájuk hatékonysága nő. • A projekt pontosan a tervek szerint halad, betartja a határidőket és a költségkeretet. • Minden hibát még az éles indulás előtt megtalálnak és kezelnek. • A rendszer megfelel minden előírt követelménynek, legyen az a teljesítmény, a megbízhatóság, vagy a biztonság. • A rendszer jól dokumentált, üzemeltethető és továbbfejleszthető.

Miért nem ilyen minden szoftverprojekt? Röviden azért, mert jó szoftvert készíteni nehéz. Sok dolgot lehet elrontani, és elég egy is, hogy az egész projektet tönkre tegye. • Rosszul felmért, vagy félreértelmezett követelmények, nem az készül el, amire a megrendelő számít. • Rosszul kitalált felhasználói felület és folyamatok, vagy elhanyagolt oktatás, így a felhasználók kínlódnak a program használatával. • A fejlesztési projekt egy „fekete doboz”, nem tudni hol tart, és milyen minőségű a készülő termék.

Miért nem ilyen minden szoftverprojekt? • Elhanyagolt, vagy rosszul végrehajtott a tesztelés, az éles üzemben jönnek elő a legkülönfélébb problémák. • Rosszul megtervezett a rendszer, a továbbfejlesztések egyre nehézkesebbé válnak, egy módosítás látszólag tőle független dolgokat is magával ránt, és a növekvő terheléssel a rendszer belassul. • A rendszer rosszul dokumentált, az üzemeltetők kénytelenek a fejlesztőkhöz fordulni szinte minden problémával.

Mi kell a sikeres szoftverfejlesztéshez? A programozókon kívül szükség van arra, aki: • szakmailag irányítja a követelmény felmérést és elemzést, • megtervezi a rendszer architektúráját • irányítja a részletes tervezési, kivitelezési és tesztelési munkákat, • elméleti és gyakorlati tapasztalattal egyaránt rendelkezik arról, hogy mitől működik jól egy szoftverprojekt, és mitől megy tönkre, • felelős a szoftver koncepcionális egységéért, és az elvárt minőségéért.

architektúra: Terv, koncepció. A kifejezést tipikusan csak nagy vonalakban rögzített működési elvek, rendszerek leírására használják, de azonos alapelvek szerint működő hardverek vagy szoftverek gyűjtőfogalmaiban (pl. "x 86 architektúra" vagy „ kliens szerver architektúra") is előfordul. koncepció: elgondolás, terv, ötlet, nézőpont

A szoftver fogalma Szoftver (software) alatt a számítógépet működtető programok, szellemi termékek összességét értjük • A szoftverfogalom tágabb körébe tartoznak mindazon • utasítások illetve ezek sorozata (program), amelyek bizonyos feladatokat digitális számítógépen megvalósítanak, • adatstruktúrák, amelyek lehetővé teszik az információfeldolgozást és • dokumentumok, amelyek leírják a programok és a rendszer működését, használatát.

A jó szoftver tulajdonságai • a szoftverterméknek rendelkeznie kell a megkövetelt funkcionalitással és az elvárt teljesítménymutatókkal • üzembiztonság (megbízhatóság és biztonságosság) • hatékonyság (nem pazarolhatja a rendszererőforrásokat) • használhatóság (rendelkeznie kell a megfelelő felhasználói interfész szel és a szükséges dokumentációval) • karbantarthatóság (követni tudja az igények változását)

Milyen jellemzők alapján értékeli az ügyfél a terméket? • költség (tágabb értelemben ideértve mindennemű ráfordítást, erőfeszítést és felhasznált időt) • minőség (szabványoknak, előírásoknak, követelményeknek való megfelelés) • rugalmasság (gyors reagálás az ügyfél és/vagy az üzleti környezet megvál tozott igényeire és követelményeire)

Az információrendszervezési projekt Az információrendszervezési projektben megoldandó feladatok: • ütemezés • minőség kezelés • tervezés, modellezés • megszervezése • kódrendszer kialakítás • be és kimenő adatok tervezés • felhasználói felület tervezés • szoftver elkészítés • dokumentálás • bevezetés, üzemeltetés

Információrendszerek projektjeinek speciális jellemzői • • • a termék nehezen szabványosítható nehéz megtalálni a legmegfelelőbb szakembert kommunikáció, együttműködés fontossága könnyen elhúzódhat, külső hatások a végtermék nem kézzel fogható (egy információrendszer átalakítása jobb ter melékenységgel jár, de nem kézzel fogható a termék) • gyorsan változó környezetben helyezkedik el • a számítógépes információrendszer úgynevezett ember gép rendszer: az em ber a meghatározó elem, a számítógép csak kiszolgáló funkciót tölt be • a vezetőktől új szemléletmódot, új ismereteket követel meg

Munkaerő feltételek: A munkaerő képezi az informatikai projektek egyik legfontosabb erőforrását. • Rendszervező • Rendszertervező • Programozó • Ügyvitelszervező • Munkaszervező • Üzemszervező • Projektvezető • Operációkutató

Rendszertervező képes a rendszervező által vázolt elképzelés, koncepció megvalósítására főleg alrendszerek tervezését végzi együttműködik a felhasználóval, a programozókkal, az ügyvitelszervezőkkel Programtervező több programnyelvet is ismer szorosan együttműködik a rendszervezővel, a rendszertervezővel, az operációkutatóval, a programozóval és az ügyvitelszervezőkkel ismeri a program és file szervezést és az operációs rendszert Programozó programnyelveket ismeri az információrendszer fejlesztés folyamatát Ügyvitelszervező feladata az ügyviteli folyamatok kézi és számítógéppel (ügyviteli progra mokkal) történő szervezése együttműködik a munka és üzemszervezőkkel

Munkaszervező feladata a munkaerő hatékony foglalkoztatása, kihasználása Üzemszervező épületkialakítás, termelő és energiaellátó berendezések, közlekedés, szállítás szervezése (logisztika) Operációkutató különböző tevékenységek, folyamatok valamilyen szempontból optimális megoldásmódjával foglalkozik programozandó algoritmus meghatározása Projektvezető felelős a fejlesztésre fordított munka hatékonyságáért, illetve az idő és költ ségkeret, valamint a minőség betartásáért

Szoftvermenedzsment • A szoftvermenedzsment vagy alkalmazás menedzsment adott szoftverhez vagy szoftvercsomaghoz kapcsolódóan a beszerzésre, fejlesztésre, bevezetésre, üzemeltetésre, szolgáltatás működtetésre, karbantartásra; továbbá az ezeket támogató folyamatokra, úgymint a dokumentálásra, minőségbiztosításra, konfiguráció kezelés re, problémakezelésre, változás kezelésre vagy az érintett humánerőforrás képzésé re koncentráló irányítási és végrehajtási funkciók együttese.

A szoftvertervezés (Mérnöki) tudományág, amely a szoftver termékek minden nézetét érinti a rendszerspecifikációtól a rendszerkarbantartásig, továbbá felöleli a projekt menedzsment gyakorlatát és a támogató eszközök fejlesztését

Szoftverköltségek • A szoftverköltségek általában dominálják a teljes rendszerköltséget • A SW/HW aránya 80% / 20% (korábban 20% / 80%). • A karbantartás és szoftverevolúció költsége gyakran többszöröse a fejlesztés költségének. • A szoftvertervezők célja költséghatékony szoftverek előállítása a lehető legrö videbb idő alatt. • Az integráció és a tesztelés költségei gyakran elérik a rendszerfejlesztés költségét. • A rendszerevolúció költsége gyakran akár négyszerese is lehet a fejlesztés költségének. • A költségek nagyban függnek a fejlesztendő rendszer típusától és a teljesít mény és üzembiztonság követelményétől. • A költségek megoszlása nagyban függ a fejlesztés modelljétől

A szoftvertechnológia A szoftverfejlesztés tipikus kérdései: • Miért tart olyan sokáig a programok befejezése? • Miért nem találják meg az összes hibát, mielőtt a programot átadnák a megrendelőnek? • Miért vannak nehézségek a fejlesztés előrehaladottságának mérésében? • Miért olyan magasak a költségek? A szoftvertechnológia (software engineering) a fentebbi kérdések megválaszolásával foglalkozik.

Szoftvertechnológia fogalma A szoftvertechnológia elvárások, számítógépes technológiák, emberek és képességeik, idő, pénz és egyéb források kezelése egy olyan termék létre hozására, amely megfelel a megrendelők elvárásainak, és ezt a terméket egy olyan folyamat során állítják elő, amelyik megfelel a fejlesztők elvárásainak. (Steward, 1987)

A szoftvertechnológia történek főbb szakaszai • A kezdeti időszak (hatvanas évek) – Kis programozói csoportok – Kis programozói környezetek – Gépi kódok és assembler nyelvek – Primitív programozási segédeszközök – Minden műveletet a programozó hajtott végre

A szoftvertechnológia történek főbb szakaszai • A fejlesztés központú időszak (hetvenes évektől a nyolcvanas évek második feléig) – Magas szintű programnyelvek – Strukturált programozás – Fejlesztésközpontú vezetés – A konfigurációkezelés bevezetése – Rendszerszoftver támogatás

A szoftvertechnológia történek főbb szakaszai • A folyamat központú időszak (nyolcvanas évek első felétől a kilencvenes évek végéig) – – – – Fejlesztő csoport Minőségbiztosítás Vezetési eszközök használata Életciklus szabványok Negyedik generációs nyelvek Alkalmazás generátorok Objektum orientált fejlesztés

A szoftvertechnológia történek főbb szakaszai • A termelés központú időszak (kilencvenes évek közepétől) – – – – – Rendszerintegrátorok csoportja Termelő környezetek kialakítása Eszköz specialisták Műhely szerű termelés Megaprogramozás Kódgenerálás Magas szintű absztrakciók Formalizmus Következetes újrafelhasználás

Szoftver fejlesztés A szoftverfejlesztési folyamat előre meghatározott célok érdekében végzett elemzési, tervezési és kivitelezési munka, amelynek eredménye egyrészt a számítógép rendszer működését biztosító programrendszer, másrészt pedig valamilyen valós folyamatot, tevékenységet támogató szoftvertermék

A fejlesztés módszertana A módszertan a módszerek egységes rendszere, amely meghatározott filozófiai álláspontra helyezkedve specifikálja az eszközöket, és a techno lógiát. A módszer bizonyos feladatok elvégzéséhez szükséges, meghatározott feltételek között érvényes szisztematikus végrehajtási mód és ennek előírása.

A fejlesztési elvek módszerek eszközök csoportosítása

A fejlesztés kulcselemei • • fejlesztési elvek fejlesztési módszerek/eljárások fejlesztési eszközök végrehajtás módja

. A szoftverfejlesztés háromszöge

A szoftver életciklusa Annak megítélésében, hogy a szoftver életciklust tárgyalva miről kell szólni, az MSZ ISO/IEC 12207 szabványt (továbbiakban ISO 12207) vesszük alapul. A szabvány egyik legnagyobb erőssége az, hogy a szoftvertermékekkel és szoftverszolgáltatásokkal a • beszerzői, • szállítói, • fejlesztői, • üzemeltetői, • karbantartói, • vezetői, minőségbiztosítói és egyéb támogatói, valamint felhasználói szerepben érintettek mindegyikének szempontjait figyelembe veszi

A szabvány tárgya, alkalmazási köre Az ISO 12207 szabvány informatikai rendszerek és szoftvertermékek, valamint szoftverszolgáltatások beszerzői, szállítói, fejlesztői, üzemeltetői, karbantartói, veze tői, minőségbiztosítási vezetői és felhasználói számára készült. A szabványt két felet érintő helyzetekben történő használatra tervezték, de lehet alkalmazni akkor is, ha a két fél ugyanabból a szervezetből való, továbbá saját ma gára vonatkozó előírásként egyetlen fél is használhatja. A szabvány leírja a szoftver életciklus folyamatok szerkezetét, de érthetően nem adja meg a folyamatokban szereplő tevékenységek és feladatok végrehajtásának, megvalósításának részleteit, azokat az alkalmazóinak kell magukra (szerződő felek re, adott szervezetre, adott projektre) nézve kötelezően rögzíteni. Így a szabvány nem ír elő semmilyen konkrét életciklus modellt vagy szoftverfejlesztési módszertant, megengedve a szabvány használójának, hogy ezeknek mindenkor az aktuális projekt sajátosságaihoz (tárgyköréhez, bonyolultságához, időtartamához, részvevőihez) leg jobban illeszkedő változatát alkalmazza.

A szabvány a szoftverek életciklusa során végbemenő folya matoknak három nagy csoportját különbözteti meg. Ezek • a fő folyamatok, • a támogató folyamatok • és a szervezeti (irányítási) folyamatok. A szabvány összetettség tekintetében felülről lefelé haladva az aktivitások három szintjét eltérő nevekkel illeti. Legfelül állnak a folyamatok, ezek összetevői a tevékenységek, az utóbbiak pedig feladatokra tagolódnak

A szoftver életciklus fő folyamatai • 1. 1 Beszerzési folyamat A rendszert, a szoftverterméket vagy szoftverszolgáltatást beszerző szervezet tevékenységeit tartalmazó folyamat. Jellemző tevékenységek: a beszerzés indítása, ajánlati felhívás készítése, szerződés elkészítése és aktualizálása, szállítófigyelés, átvétel és befejezés. • 1. 2 Szállítási folyamat A beszerzőt a rendszerrel, a szoftvertermékkel vagy szoftverszolgáltatással ellátó szervezet tevékenységeit tartalmazó folyamat. Jellemző tevékenységek: a rendelés (ajánlatkérés) megválaszolása, szerződéskötés, tervezés, végrehajtás és ellenőrzés, átvizsgálás és értékelés, leszállítás és befejezés.

• 1. 3 Fejlesztési folyamat A szoftverterméket meghatározó és kifejlesztő szervezet (leginkább egy projekt) tevékenységeit tartalmazó folyamat. • 1. 4 Üzemeltetési folyamat A számítógépes rendszer üzemeltetését (rendelkezésre állását) annak valós környezetében a felhasználói számára biztosító szervezet tevékenységeit tartalmazó folya mat. • 1. 5 Karbantartási folyamat A szoftvertermék karbantartását biztosító; vagyis a szoftver aktualitásának és üzemeltethetőségének fenntartása céljából szükséges módosításait intéző szervezet tevékenységeit tartalmazó folyamat. Jellemző tevékenységek: probléma és módosításelemzés; módosítás kivitelezése; a karbantartás vizsgálata, elfogadása; átállás az új szoftverváltozatra, az elavult változat visszavonása.

A szoftver életciklus támogató folyamatai • 2. 1 Dokumentálási folyamat Az életciklus folyamatok által előállított ismeretek (értelmezések, követelmények, megoldások, megállapodások, döntések, utasítások, tervek, tények) rögzítésének tevékenységeit (dokumentum tervezés és fejlesztés, előállítás, karbantartás) támo gató folyamat. (Például a követelmény leírások sablonjának elkészítése vagy a leírások utólagos formai szerkesztése ide tartozik, de a követelmény leírások tartalmi szerkesztése a fejlesztési folyamat része).

• 2. 2 Konfigurációkezelési folyamat A konfiguráció kezelés a szoftverkomponensek, a szoftverekből felé pülő rendszerek változatainak (verzióinak) azonosítását; a verziók változtatásainak felügyeletét, állapotfelmérését, értékelését, kiadását, leszállítását, visszavonását; továbbá mindezek nyilvántartását jelenti. Konfigurációkezelésre olyan termékek esetében van szükség, amelyek több változatban készülhetnek el. A szoftvertermék tipikusan ilyen: lehet egy üzemi környezetben, használatban lévő változata; de már elkészült a használt változat bizonyos hibáit, hiányosságait kiküszöbölő újabb változata, amely tesztelés alatt áll; közben folyamatban lehet egy lényegesen bővebb tudású változat fejlesztése is.

• 2. 3 Minőségbiztosítási folyamat Olyan tevékenységeket tartalmazó folyamat, amelyek objektív biztosítékot szolgáltat nak arra, hogy a szoftvertermékek és szoftverfolyamatok megfelelnek a megfogalmazott követelményeknek és követik a kialakított terveket. Speciális területei a termékbiztosítás, a folyamatbiztosítás, a minőségügyi rendszer biztosítása. – Az együttes átvizsgálás, a felülvizsgálás, az igazolás és az érvényesítés a minőségbiztosítás operatív funkciói.

• 2. 4 Igazolási folyamat – Verifikálás A beszerző, a szállító vagy valamilyen független fél olyan tevékenységeit tartalmazó folyamat, amely szoftvertermékek igazoló ellenőrzésére szolgál a szoftverprojekttől függő, különböző mélységben. Az igazolási folyamat keretében azt kell bizonyítani, hogy a termék megfelel a rá vonatkozó terveknek (specifikáció). • 2. 5 Érvényesítési folyamat – Validálás A beszerző, a szállító vagy valamilyen független fél olyan tevékenységeit tartalmazó folyamat, amelyek a projektben szereplő szoftvertermékek érvényesítő ellenőrzésére szolgálnak. Az érvényesítési folyamat keretében azt kell bizonyítani, hogy a termék megfelel a rá vonatkozó szerződéses követelményeknek

• 2. 6 Együttes átvizsgálási folyamat Valamilyen projekttevékenység helyzetének vagy termékei állapotának értékelésére szolgáló tevékenységekből álló folyamat. Ezt a folyamatot tetszőleges két fél alkal mazhatja, ahol valamilyen együttes ülésen az egyik fél (átvizsgáló fél) átvizsgálja a másik felet (átvizsgált fél). • 2. 7 Felülvizsgálási folyamat Ezt a folyamatot tetszőleges két fél alkalmazhatja, ahol az egyik fél (felülvizsgáló fél) felülvizsgálja a másik fél (felülvizsgált fél) szoftvertermékeit és tevékenységeit. Olyan tevékenységekből áll, amelyek megállapítják a követelményeknek, terveknek és szerződésnek való megfelelést. (Tehát a felülvizsgálat keretében történhet akár iga zolási, akár érvényesítési célú vizsgálat, a lényeg hogy ezt két fél – a felülvizsgált és a felülvizsgáló – együttműködésben hajtja végre

• 2. 8 Probléma megoldási folyamat Ez a folyamat a fejlesztés, az üzemeltetés, a karbantartás vagy más folyamat végrehajtása során feltárt problémák elemzésére és kiküszöbölésére szolgál, bármi legyen is azok természete és forrása. (A problémák elemzése változtatási igények megfogalmazásához is vezethet, ilyenkor a probléma megoldási folyamat változás kezelési folyamatba megy át. )

A fejlesztési, üzemeltetési, problémakezelési és karbantartási folyamatok kapcsolatai

Változáskezelési folyamat A szabványban nem jelenik meg külön folyamatként a változáskezelés. Ez nem jelenti azt, hogy a szabvány készítői teljesen megfeledkeztek róla, csupán annak feladatait részben a konfigurációkezelési folyamatnak, részben a problémamegoldási folyamatnak adták át. A konfigurációkezelés és azon belül a konfigurációfelügyelet leírásából következik, hogy a szoftvertermékre vonatkozó változáskezelést – tehát a változtatási kérelmek nyilvántartásba vételét, elemzését, a jóváhagyott változtatási igényt teljesítő konfiguráció kijelölését, a teljesítés felügyeletét – a konfiguráció kezelés részének tekintették. Ha azonban egy (beszerzési vagy fejlesztési) projekten belül felmerülő változtatási igény nem a projekt termékére, hanem a projekt tevé kenységeire, ütemezésére, erőforrásaira, az alkalmazott módszerekre vagy a költségvetésre vonatkozik, akkor az ilyen igény kezelése a szabványban inkább a probléma megoldási folyamat részét képezi.

Szoftverfolyamat A szoftverfolyamat olyan tevékenységek és kapcsolódó eredmények halmaza, ame lyek célja a szoftver kifejlesztése és/vagy továbbfejlesztése. • Számos szoftverfolyamat létezik, de néhány tevékenység azért minden szoftver folyamatban közös: • Követelményelemzés/szoftverspecifikáció: a szoftver működésének, és a működésre vonatkozó megszorításoknak a definiálása (mit kell tudnia a rendszernek). • Szoftverfejlesztés: a szoftver elkészítése a specifikáció alapján. • Validáció: annak ellenőrzése, hogy a szoftver valóban az, amit az ügyfél megrendelt. • Szoftverevolúció: a szoftver átalakítása a megváltozott igényeknek megfelelően, a szoftver utóélete, továbbfejlesztése, javítása.

A fejlesztési folyamat életciklusa

A szoftverfolyamat modellje a szoftverfolyamat egyszerűsített leírása egy bizonyos nézőpontból: Szoftverfolyamat perspektívák: – munkafolyam nézőpont – adatfolyam nézőpont – szerepkör / tevékenység nézőpont • Munkafolyam (workflow) nézőpont A tevékenységek folyamatbeli sorrendiségét mutatja azok bemeneteivel, kimene teivel és függőségeikkel. Minden tevékenység egy emberi cselekmény.

• Adatfolyam (dataflow) nézőpont A folyamatokat olyan tevékenységekre bontja, amelyek mindegyike valamilyen adat transzformációt hajt végre bemutatja, hogy a folyamat bemenete hogyan alakul át kimenetté, pl. a specifikációból hogyan lesz kész szoftver – minden tevékenység em berek, vagy gépek által végrehajtandó transzformáció. • Szerepkör/tevékenység (role/action) nézőpont A szoftverfolyamatban résztvevő emberek szerepköreit, és a felelősségük alá tartozó tevékenységeiket mutatja be

• Szoftverfejlesztési nézetek: – Vízesés modell – V modell – Inkrementális fejlesztés – Evolúciós (prototípus) fejlesztés – Spirális modell – Rendszerintegráció újrafelhasználható komponensekből

Vízesés modell „Vízesés” megközelítési módszerben az egyes tevékenységek a folyamat különálló fázisai, (pl. specifikáció, szoftvertervezés, implementáció, tesztelés, stb). Amikor egy tevékenység befejeződött, csak akkor kezdődhet el a következő.

Vízesés modell jellemzői • A modell a folyamat alapvető tevékenységeit különálló fázisként tekinti. Ezek a fázisok lépcsősen kapcsolódnak egymáshoz • A vízesés modell problémája abból adódik, hogy a korai szakaszokban kell bizonyos kérdésekben állást foglalni. Akkor lehet jól alkalmazni, ha a követelmények előre jól ismertek. • Az iterációk költségesek, hiszen a fázisok lezárásaként elkészülő dokumentumok előállítása idő és költségigényes. • Egy két iteráció után befagyasztják az egyes fázisokat, és a következő fázisra térnek át.

• A modell előnyei: Világos struktúra; a projekt egyszerűen ütemezhető, irányítható. • A modell hátrányai: Mivel a követelmények meghatározása és végleges rögzítése az egyszeri elemzési fázis feladata, ez a modell feltételezi, hogy a követelmények az elején pontosan ismertek és később nem változnak. A valóságban a legtöbb esetben ez nem teljesül. Az elemzési szakasz végére nem lesz ismert minden követelmény, hiszen a felhasználó sem tudja pontosan, mit szeretne (majd akkor lesznek ötletei, ha lát valamit működni a rendszerből). Az összegyűjtött követelményeket is másképpen értelmezi a felhasználó és a fejlesztő; hosszabb projekt során a követelmények egy része közben elavul, helyettük újak keletkeznek. Így mind a követelmények, mind a tervek nem megfelelőségét a felhasználó csak a működő szoftver bemutatásakor veszi észre; illetve a fejlesztő az időben fel nem fedezett hibák miatti problémák tömegével a finisben, az integráció során szembesül

„V” modell A V modell a vízesés modell speciális változatának tekinthető (11. ábra). A V modell életciklus elképzelése nemcsak az egyes fázisok időbeli sorrendjéről szól, hanem arról is, hogy az egyes fázisokban mely korábbi fázisok termékeit kell felhasználni; illetve az adott fázis tevékenységét és termékét mely korábbi fázisban leírt követelmények, illetve elkészített tervek alapján kell ellenőrizni (verifikálni).

„V” modell jellemzői • Azon felül, hogy ez a modell nagyon jó támpontokat ad a verifikáció végrehajtásához, előnyeiről és hátrányairól hasonlók mondhatók el, mint a vízesés modellnél.

Evolúciós fejlesztés • nem választja szét, hanem összemossa a specifikáció, a fejlesztés, és a kódolás fázisát • egy kezdeti specifikációból előállít egy prototípust, a megrendelő ennek alapján finomítja a specifikációt. Ebből a fejlesztők készítenek egy újabb verzi ót, és a folyamat addig ismétlődik, amíg a kívánt rendszer el nem készül.

A modellnek többféle változata ismert, ezek főleg abban különböznek, hogy a prototípus • csak a követelményeket teszteli • a terveket is teszteli

Evolúciós fejlesztés jellemzői A modell előnyei: Gyorsan elkészülnek az ember gép kommunikációval kapcsolatos funkciók; idejében kiderülnek a félreértések, pontosabbak lesznek a követelmények, kipróbálhatók az alternatív megoldások, csökken a kockázat. A fejlesztő és a felhasználó személyes együttműködése növeli a felhasználó elégedettségét, a fej lesztési célok iránti elkötelezettségét

• A modell hátrányai: Egy átfogó projektterv helyett a fejlesztést a felhasználó ötletei irányítják, így nincs átlátható folyamat, nem mondható meg, hogy a „kész állapothoz” képest hol tart a projekt. A módszer újabbnál újabb igények támasztására ad ötletet a felhasználónak, ezért az igények folyamatos növekedésének gátat kell szabni a rendszer határainak megvonásával és egy erőskezű projektvezetéssel.

Inkrementális fejlesztés • Az inkrementális fejlesztési szemlélet a részfeladatok kidolgozását egy kezdeti modellel indítja, majd ezt a gyakorlati hasznosság, és a felhasználói követelmények szerint több lépésben finomítja. Ezzel valójában az egyes elemeknek több verziója készül el, ezeket nevezzük inkrementumoknak. • Mivel a fejlesztés során a komponensek elkészítésének sorrendje nincs szigorúan szabályozva, a fejlesztés kockázatának csökkentése érdekében először a problema tikus részeket érdemes kifejleszteni. Ha ezek elfogadhatóak, akkor a már meglévő termékből kiindulva elkészíthető egy megnövelt képességű, újabb változat. (inkrementális: növekvő)

Inkrementális fejlesztés jellemzői • Az inkrementális fejlesztés nagy hátránya, hogy rendszerint hosszú átfutási időt, és soklépéses fejlesztés igényel, hibái ellenére mégis egyértelmű előnyeként kell felhozni, hogy hatékony megoldást kínál olyan fejlesztéseknél, ahol: • nem definiálhatók előre pontosan a működés architektúrája és algoritmusai • a megoldhatóság legalkalmasabb technikai technológiai feltételrendszere a pontos, fejlesztéssel kapcsolatos elvárások

Spirális modell • A szoftverfolyamatot nem tevékenységek, és a közöttük található esetleges visszalépések sorozataként tekinti, hanem inkább spirálként reprezentálja. • A spirálban minden egyes kör a szoftverfolyamat egy fázisát jelenti

A spirált 4 szektorra oszthatjuk fel: 1. Célok kijelölése: egy adott projektfázis által kitűzött célok meghatározása 2. Kockázat becslése és csökkentése: minden egyes felismert projektkockázati tényező esetén részletes elemzésre kerül sor. Ha például fennáll a kockázata annak, hogy a követelmények nem megfelelők, akkor prototípust lehet fejleszteni.

3. Fejlesztés és validálás: a kockázatok mérlegelése után egy megfelelő fejlesztési modellt választunk. Például, ha a felhasználói felület kérdései domi nánsak, akkor evolúciós fejlesztés, ha az alrendszerek integrálása kritikus, akkor vízesésmodell. 4. Tervezés: A projektet áttekintjük, és eldöntjük, hogy elkezdhető e a következő fázis. Ha igen, akkor felvázoljuk a projekt következő fázisát

Fontos különbség az inkrementális és a spirális modell között, hogy a spirális kimondottan számol a kockázati tényezőkkel.

Rendszerintegráció újrafelhasználható komponensekből • A modell szerinti fejlesztés az új rendszert újrafelhasználható komponensekből állítja össze. • Feltételezzük, hogy a rendszer egyes komponensei már léteznek. Ekkor a feladat a megfelelő elemek kiválasztására és integrálására „egyszerűsödik”. • Ha ismert olyan implementáció, amely hasonlít a kívánthoz, akkor célszerű azt átalakítani, majd beépíteni a rendszerbe. Ez elősegíti a gyors fejlesztést.

Fejlesztő és tesztelő eszközök A nagy, komplex informatikai rendszerek, szoftveralkalmazások fejlesztése napjaink ban rendkívüli kihívást jelent a fejlesztők számára. A gazdasági versenyre való gyors reagálás, az új digitális technológiák alkalmazása, a hatékonyabb módszerek kihasz nálása a hagyományos megoldásokkal már nem lehetséges

Annak érdekében, hogy garantálni lehessen a fejlesztett alkalmazás biztonságos, hibamentes működését, már a fejlesztési munka során arra kell törekedni, hogy valós folyamatok érthető módon legyenek modellezve, ezek a modellek egyszerűen módosíthatóak legyenek, és hogy a fejlesztő és a felhasználó egyformán értelmezze azokat. A fejlesztési munka különböző technikai támogatással végezhető, a fejlesztésben részvevők közötti párbeszéd eltérő formákban valósítható meg, a dokumentációk készítésénél pedig számos szemléltetésre alkalmas eszköz áll rendelkezésre

• A fejlesztés alapvető célja a valós folyamatok számítógéppel történő támogatása, egy olyan szoftvertermék kifejlesztése, amely magas szinten elégíti ki a felhasználó elvárásait. Egy elkészített program akkor adható át a felhasználónak, ha mind a reális folyamatokból vett, mind pedig a szélsőséges adatokkal kipróbálták, és a szoftver minden esetben hibátlanul működve az elvárt eredményt produkálta. • A tesztelés célja a szoftvertermék elvárt minőségének garantálása, a tesztadatok előírása, a tesztelési és elfogadási kritériumok definiálása, a lefuttatott eredmények minősítése pedig a tesztelő szakemberek feladata.

Fejlesztő eszközök • 4 GL, 5 GL alkalmazásfejlesztők: a 4 GL ek platform független, feladatorientált környezetet biztosítanak a fejlesztők (programozók) szá mára. Az adatbázis definiálási és manipulációs megoldásokkal, a CASE eszközök höz való csatlakozás lehetőségével a változtatásokhoz könnyen igazodó fejlesztési támogatást nyújtanak.

Ezek a fejlesztőeszközök számos területen segítik a programfejlesztők munkáját: 1. Környezeti feltételek pontos specifikálása, kezelése, dialógustervezés, képer nyőszerkesztés 2. Adatspecifikációs, lekérdezési és – manipulációs lehetőségek – Adatszótár – Adatbázis fizikai struktúrája – Adatbázis elemek létrehozása, törlése, módosítása – Lekérdezések létrehozása

3. Programtervezési támogatás – Adatnézet, programszótár – Kifejezéstábla – Folyamatleírás tábla 4. Kódgenerálás 5. Grafikus felhasználói felület tervezése, létrehozása 6. Output terv generálása, jelentéskészítés – Interaktív űrlapok – Űrlapok összekapcsolása – Mezők verifikálása

Előnyei: • csökken a fejlesztési idő, nincsenek szemantikai hibák, bizonyos funkciók tesztelésére nincs szükség • Növekszik a fejlesztési munka hatékonysága, optimalizált programok készülnek, nincs szükség a program szintaktikájának pontos ismeretére, egyszerűen készíthetők prototípus változatok. • A nyelvek rugalmassága leegyszerűsíti a fejlesztés során a változtatások átvezetését

• jól illeszkedik a Windows ban megszokott felülethez. • A szabványos megoldások lehetővé teszik a különböző környezetben végzett munkát, és biztosítják a platform függetlenséget, hordozhatóságot. • Támogatják a web böngészőkön alapuló adatbázis felületek fejlesztését. • Rendelkeznek csoportmunka támogatás képességgel, javul a tervező és a programozó közti kommunikáció.

Hátrányai: • A 4 GL/5 GL es fejlesztések termékei a működtetés során lassúbbak, mint a hagyományos nyelven elkészített alkalmazások, összetett rendszerek esetében pedig nemcsak az egyes programok belső struktúrája, hanem a programrendszer architektúrája is áttekinthetetlenné válhat.