Informatikai projektek

Az előadások a következő témára: "Informatikai projektek"— Előadás másolata:

1 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

2 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

3 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ő.

4 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.

5 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-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.

6 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.

7 architektúra: Terv, koncepció
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. "x86 architektúra" vagy „ kliens-szerver architektúra") is előfordul. koncepció: elgondolás, terv, ötlet, nézőpont

8 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.

9 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)

10 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)

11 Az információrendszer-szervezési projekt
Az információrendszer szervezé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

12 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

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

14 Rendszertervező képes a rendszerszervező á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 rendszerszervező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 ismer 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

15 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

16 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.

17 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

18 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

19 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.

20 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)

21 A szoftvertechnológia történeté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

22 A szoftvertechnológia történeté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

23 A szoftvertechnológia történeté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

24 A szoftvertechnológia történeté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

25 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

26 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.

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

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

29 . A szoftverfejlesztés háromszöge

30 A szoftver életciklusa
Annak megítélésében, hogy a szoftver-életciklust tárgyalva miről kell szólni, az MSZ ISO/IEC 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

31 A szabvány tárgya, alkalmazási köre
Az ISO 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.

32 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

33

34 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.

35 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.

36 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).

37 2.2 Konfigurációkezelési folyamat
A konfiguráció-kezelés a szoftverkomponensek, a szoftverek, 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.

38 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.

39 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

40 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

41 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.)

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

43 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.

44 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.

45 A fejlesztési folyamat életciklusa

46 A szoftverfolyamat modellje
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-egy emberi cselekmény.

47 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

48 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

49 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ő.

50

51 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.

52 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

53 „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).

54

55 „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.

56 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.

57 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

58

59 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

60 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.

61 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ő)

62

63 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

64 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-egy fázisát jelenti

65

66 A spirált 4 szektorra oszthatjuk fel:
Célok kijelölése: egy adott projektfázis által kitűzött célok meghatározása 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.

67 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. 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

68 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.

69 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.

70

71 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

72 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

73 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.

74 Fejlesztő eszközök 4GL, 5GL alkalmazásfejlesztők:
a 4GL-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.

75 Adatspecifikációs, -lekérdezési és –manipulációs lehetőségek
Ezek a fejlesztőeszközök számos területen segítik a programfejlesztők munkáját: Környezeti feltételek pontos specifikálása, kezelése, dialógustervezés, képer­nyőszerkesztés 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

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

77 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

78 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ó.

79 Hátrányai: A 4GL/5GL-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.