Szoftvermenedzsment 4. fejezet – A szoftverfolyamat
Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai és Gazdasági Intézet Soós Sándor 2007. július
Szoftvermenedzsment
Soós Sándor
1
A szoftverfolyamat ●
Ahogyan az első fejezetben megbeszéltük: –
–
– – ●
A szoftverfolyamat tevékenységek és kapcsolódó eredmények olyan sora, amelyek egy szoftvertermék előállításához vezetnek Ezek történhetnek a szoftverfejlesztés kezdeteitől, de gyakran egy meglévő szoftver módosítására irányulnak Nehezen gépesíthető, mert nagyon sok emberi tényezőtől függ, kreativitást igényel Egyes fázisai támogathatók CASE eszközökkel
CASE: Computer Aided Software Engineering
Szoftvermenedzsment
Soós Sándor
2
A szoftverfolyamat fázisai ●
Sokféle megközelítés létezik, de vannak közös pontok: – – – –
Szoftverspecifikáció Szoftvertervezés és implementáció Szoftvervalidáció Szoftverevolúció
Szoftvermenedzsment
Soós Sándor
3
A szoftverfolyamat modelljei ●
Nincs olyan modell, ami minden folyamatra alkalmazható lenne. Vannak különböző megközelítésmódok, amelyeket ismerve, vegyesen alkalmazhatjuk ezeket: – – – –
Vízesés modell Evolúciós fejlesztés Formális rendszerfejlesztés Újrafelhasználás alapú fejlesztés
Szoftvermenedzsment
Soós Sándor
4
A vízesés modell ●
●
●
●
Ez a szoftverfolyamat első publikált modellje (1970) Nevezik szoftveréletciklusnak is Az ábrán látszik, hogy honnan kapta a nevét Mit jelentenek a nyilak? Szoftvermenedzsment
Soós Sándor
5
Követelmények elemzése és meghatározása ●
● ● ●
A rendszer által nyújtandó szolgáltatások, és a megszorítások a megrendelővel, illetve a leendő felhasználókkal történő konzultáció(k) alapján alakulnak ki Ezeket részletesen kifejtjük, írásba foglaljuk Aláíratjuk a felhasználóval Ez alkotja a rendszerspecifikációt
Szoftvermenedzsment
Soós Sándor
6
Rendszer- és szoftvertervezés ●
● ●
● ●
A rendszertervezés fázisában választjuk szét a hardver és szoftver követelményeket Kialakítjuk a rendszer átfogó architektúráját A szoftvertervezés fázisában meghatározzuk az alapvető szoftverabsztrakciókat, azaz eldöntjük, hogy a rendszer egyes elemeit milyen szoftvereszközökkel fogjuk megvalósítani Meghatározzuk az elemek közötti kapcsolatokat Mindezt írásban rögzítjük
Szoftvermenedzsment
Soós Sándor
7
Implementáció és egységteszt ●
●
Ebben a fázisban megvalósítjuk a szoftvertervben meghatározott szoftvermodulokat Az egységteszt ellenőrzi, hogy az egyes modulok megfelelnek-e a specifikációnak
Szoftvermenedzsment
Soós Sándor
8
Integráció és rendszerteszt ● ● ●
Integráljuk az elkészült programmodulokat Teszteljük a teljes rendszert Célszerű fokozatosan végezni az integrációt és a tesztelést – – –
●
először két modult integrálunk és tesztelünk majd hozzákapcsoljuk a harmadikat, és teszteljük és így tovább, amíg minden modult be nem építettünk a rendszerbe
Sikeres rendszerteszt után a rendszer átadható a megrendelőnek
Szoftvermenedzsment
Soós Sándor
9
Működtetés és karbantartás ●
● ●
●
Általában ez a szoftver életciklus leghosszabb szakasza, de nem mindig. Mondjunk egy példát, amikor nem így van! Megtörtént a rendszer telepítése és használatbavétele A karbantartás elemei: – – –
olyan hibák kijavítása, amelyek nem derültek ki a korábbi fázisokban az egyes modulok továbbfejlesztése a rendszer továbbfejlesztése újabb szolgáltatások megvalósításával
Szoftvermenedzsment
Soós Sándor
10
Megjegyzések a vízesés modellhez ●
● ●
●
Az egyes fázisok eredményei különböző dokumentumok Ezeket mindkét félnek jóvá kell hagynia, aláírás Elvileg akkor indulhat a következő fázis, amikor az előző sikeresen befejeződött, a gyakorlatban azonban ezek átfedhetik egymást Lehet, hogy vissza kell lépnünk egy korábbi fázisra – –
tervezés közben derül ki, hogy módosítanunk kell a specifikációt implementáció közben derül ki, hogy módosítanunk kell a tervet
Szoftvermenedzsment
Soós Sándor
11
Megjegyzések a vízesés modellhez ●
●
●
●
●
A szoftverfolyamat általában nem lineáris folyamat, hanem többszörös iterációk sorozata A leggyakrabban akkor szükséges visszalépés, amikor megváltoznak a megrendelő elvárásai Ha ez gyakran előfordul, az felboríthatja a rendszer struktúráját Ezért a modell akkor használható jól, ha előre ismertek a felhasználói elvárások Maga a gondolkodásmód azonban máskor is jól használható, ha nem ragaszkodunk szigorúan a merev határokhoz
Szoftvermenedzsment
Soós Sándor
12
Evolúciós fejlesztés ●
Alapelv: – – – –
●
fejlesszünk ki egy kezdeti implementációt mutassuk meg a megrendelőnek módosítsuk az elvárásainak megfelelően ezt ismételjük addig, amíg az aktuális verzió teljesen meg nem felel a megrendelő elvárásainak
Ez csak akkor alkalmazható, ha a megrendelő elfogadja ezt az eljárást
Szoftvermenedzsment
Soós Sándor
13
Evolúciós fejlesztés ●
Ez a módszer nem választja szét mereven a specifikációt, a fejlesztést és a validálást, így lehetővé teszi a párhuzamos munkát és a gyors visszacsatolást
Szoftvermenedzsment
Soós Sándor
14
Az evolúciós fejlesztés típusai 1.Feltáró fejlesztés •
• •
A folyamat célja, hogy a megrendelővel együtt alakítsuk ki a követelményeket, majd a végleges rendszert A fejlesztés a rendszer ismert részeivel kezdődik Egyre több új funkciót építünk a rendszerbe
2.Eldobható prototípus készítés •
•
A folyamat célja, hogy egyre jobban megértsük a követelményeket A prototípus célja, hogy jobban megértsük a megrendelő igényeit
Szoftvermenedzsment
Soós Sándor
15
Az evolúciós fejlesztés előnyei ●
●
●
Hatékonyabb, mint a vízesés modell, ha olyan rendszert akarunk fejleszteni, amely közvetlenül megfelel a megrendelő elvárásainak A rendszerspecifikáció inkrementálisan, fokozatosan fejleszthető Ahogyan egyre jobban megértjük a felhasználó igényeit, azokat beépítjük a specifikációba és magába a rendszerbe
Szoftvermenedzsment
Soós Sándor
16
Az evolúciós fejlesztés hátrányai ●
A folyamat nem jól látható –
●
A rendszerek gyakran szegényesen strukturáltak. –
●
A folyamat előrehaladása nem jól látható kívülről, a vezetőség nehezen tudja követni a projekt alakulását A folyamatos változtatások hatására gyakran elromlik a rendszer szerkezete
Speciális eszközökre és technikákra van szükség – –
A gyors fejlesztéshez speciális eszközökre van szükség (program generátorok) Ezek nem mindig kompatibilisek más eszközökkel
Szoftvermenedzsment
Soós Sándor
17
Összehasonlítás ●
●
●
A tapasztalatok szerint a rövid élettartamú és kis (kevesebb, mint 100 ezer programsor), vagy közepes (500 ezer sorig) méretű rendszerek esetében az evolúciós fejlesztés a leghatékonyabb A nagy és hosszú élettartamú rendszerek esetében a problémák túlságosan nagy veszélyt jelentenek Ezek esetében egy kombinált eljárás használata javasolt
Szoftvermenedzsment
Soós Sándor
18
Kombinált megoldás ●
● ●
●
Evolúciós megközelítéssel készítünk egy prototípust, aminek felhasználásával kialakítjuk a pontos specifikációt Eldobjuk a prototípust Vízesés módszerrel újraimplementáljuk a rendszert A rendszer bizonyos részeit, pl. a felhasználói felületet feltáró programozással fejleszthetjük ki leghatékonyabban
Szoftvermenedzsment
Soós Sándor
19
Formális rendszerfejlesztés ●
A vízesés modellhez hasonló megközelítés, de – –
nagyon precízen, matematikai módszerekkel fogalmazzuk meg a rendszerspecifikációt ezt a specifikációt matematikai transzformációk segítségével fokozatosan átalakítjuk futtatható programmá
Szoftvermenedzsment
Soós Sándor
20
Formális rendszerfejlesztés
●
●
●
A formális specifikációt, elemi transzformációk sorozatával, lépésekben alakítjuk át futtatható programmá Olyan transzformációkat hajtunk végre, amelyekről be tudjuk bizonyítani, hogy „helyesek” Ezért nincsen szükség arra, hogy a teljes program helyességét bebizonyítsuk
Szoftvermenedzsment
Soós Sándor
21
A formális rendszerfejlesztés előnye és hátránya ●
●
●
Ezt az eljárás szinte képtelenség megvalósítani nagyobb programok esetén, legalábbis nagyon nagy ráfordítás szükséges hozzá Vannak azonban olyan esetek, amikor szükség van arra, hogy formális módszerekkel is garantálni tudjuk a program helyességét: – biztonsági rendszerek – kritikus rendszerek (űrhajózás, katonaság) A nagy rendszerek közötti kölcsönhatások következményeit azonban ez a módszer sem tudja garantáltan hibátlanul kezelni, erre itt is hasonló tesztelési módszereket kell használni, mint a többi módszertan esetében
Szoftvermenedzsment
Soós Sándor
22
Újrafelhasználás-orientált fejlesztés ●
●
●
●
Valamilyen szinten minden projektben előfordul, hogy felhasználunk kész komponenseket Amikor észrevesszük, hogy egy adott feladatra létezik kész megoldás, vagy legalább részmegoldás, akkor elővehetjük azt, szükség szerint módosítjuk, majd beépítjük a projektbe Az evolúciós megközelítés esetében ez szinte kötelező a gyors prototípus készítés érdekében A napjainkban divatos komponens alapú tervezés is ezen az ötleten alapszik
Szoftvermenedzsment
Soós Sándor
23
Újrafelhasználás-orientált fejlesztés
●
A folyamat eleje és vége megegyezik a többi módszertannal, a középső fázisok azonban eltérőek
Szoftvermenedzsment
Soós Sándor
24
Az újrafelhasználás-orientált fejlesztés fázisai ●
Komponenselemzés: –
●
az elkészült követelményspecifikáció alapján meg kell vizsgálni, hogy léteznek-e kész komponensek, amelyek felhasználhatók a követelmények kielégítésére
Követelménymódosítás: – – –
a talált komponenseket össze kell vetni a követelményekkel gyakori eset, hogy módosítani kell a követelményeket ha ez nem lehetséges, akkor a talált komponens nem használható fel
Szoftvermenedzsment
Soós Sándor
25
Az újrafelhasználás-orientált fejlesztés fázisai ●
Rendszertervezés újrafelhasználással –
– ●
ebben a fázisban meg kell tervezni a rendszer szerkezetét úgy, hogy a rendelkezésre álló kész komponensek beépíthetők legyenek amelyik feladatra nincsen kész komponens, azt el kell készíttetni
Fejlesztés és integráció – – –
el kell készíteni az új komponenseket integrálni kell a meglévő és az új komponenseket ebben az esetben az integráció kapja a fő hangsúlyt
Szoftvermenedzsment
Soós Sándor
26
Újrafelhasználás-orientált fejlesztés előnyei és hátrányai ●
Előnyök: – –
●
kevesebb modult kell kifejleszteni csökken a költség és az időszükséglet
Hátrányok: – – –
kompromisszumokat kell kötni a követelményekben lehet, hogy a rendszer így nem elégíti ki a megrendelő igényeit nem rendelkezünk teljes felügyelettel a rendszer minden komponense felett, ez gondot okozhat például a továbbfejlesztés során
Szoftvermenedzsment
Soós Sándor
27
Folyamatiteráció ●
●
●
Minden eddigi módszernek vannak előnyei és hátrányai A legtöbb fejlesztés esetében több megközelítési módot kell alkalmazni, azaz egy hibrid modellt használunk Az is gyakran előfordul, hogy a folyamat egyes fázisait meg kell ismételni például a követelmények megváltozása miatt
Szoftvermenedzsment
Soós Sándor
28
Hibrid modellek ●
Inkrementális fejlesztés –
●
Spirális fejlesztés –
●
●
a specifikációt, a tervezést és az implementálást is kis szakaszokra (inkremensek) osztjuk és ezeket egymás után több fordulóban hajtjuk végre A rendszer fejlesztése egy spirál vonallal jellemezhető a kezdeti vázlattól a kész rendszerig
Mindkét módszer esetében a specifikációt a rendszerrel együtt fejlesztjük, így a teljes specifikáció nem lehet része a szerződésnek Ezt nem minden megrendelő fogadja el!
Szoftvermenedzsment
Soós Sándor
29
Inkrementális fejlesztés ●
●
●
●
A vízesés modell megköveteli, hogy az ügyfél véglegesítse a specifikációt mielőtt a tervezés elkezdődne, a tervezőtől pedig azt, hogy az implementáció megkezdése előtt véglegesítse a rendszertervet Ennek eredménye egy jól menedzselhető, tiszta szerkezet, ami azonban nem nyújt lehetőséget a menet közbeni változtatásokra Az evolúciós megközelítési mód megengedi, hogy későbbre halasszuk a követelményekkel és a tervezéssel kapcsolatos döntéseket, ennek azonban egy gyengén strukturált, nehezen menedzselhető rendszer a következménye Jó lenne kombinálni a két módszer előnyeit!
Szoftvermenedzsment
Soós Sándor
30
Inkrementális fejlesztés
Szoftvermenedzsment
Soós Sándor
31
Inkrementális fejlesztés ●
● ●
● ● ●
A vázlatos követelménymeghatározás után csoportokba soroljuk az elvárásokat Kiválasztjuk a megrendelő számára legfontosabb funkciókat Az ezeket megvalósító inkremenst a legmegfelelőbb módszertan szerint részletesen specifikáljuk, megtervezzük, kifejlesztjük, teszteljük és integráljuk a rendszerbe A megrendelő elkezdheti használni a részrendszert Ha minden igényt kielégítettünk, akkor készen vagyunk Ha maradtak még kielégítendő követelmények, akkor folytassuk a következő inkremenssel
Szoftvermenedzsment
Soós Sándor
32
Az inkrementális fejlesztés előnyei ●
●
●
A megrendelőnek nem kell megvárnia, amíg a teljes rendszer elkészül, ha az első inkremensbe soroljuk a legfontosabb funkciókat, akkor ezeket már a fejlesztés legelején használatba veheti Az inkremensek specifikálásához felhasználhatjuk a korábbiak implementálása, sőt akár használata során szerzett tapasztalatokat Kisebb az esélye annak, hogy a teljes projekt kudarcba fullad, legalább részben nagy valószínűséggel elkészül
Szoftvermenedzsment
Soós Sándor
33
Az inkrementális fejlesztés előnyei ●
●
Minden inkremenst a legmegfelelőbb módszertannal fejleszthetünk Ha a legfontosabb szolgáltatásokat az első inkremensekbe soroljuk, akkor ezeket fogjuk a legtöbbször használni, tesztelni, mielőtt a teljes fejlesztés véget ér, így kisebb az esélye annak, hogy kritikus funkciókban hibák maradnak
Szoftvermenedzsment
Soós Sándor
34
Spirális fejlesztés ● ●
A szoftverfolyamatot egy spirálként ábrázoljuk. Minden egyes kör a folyamat egy-egy fázisának felel meg – – –
●
legbelső kör: megvalósíthatóság a követelmények meghatározása a rendszer tervezése
Minden egyes ciklust négy fázisra bontunk, amelyek minden ciklusban hasonló jellegű tevékenységet jelentenek
Szoftvermenedzsment
Soós Sándor
35
Szoftvermenedzsment
Soós Sándor
36
A spirális fejlesztés ciklusainak négy fázisa ●
Célok kijelölése: – –
●
az adott ciklus által kitűzött célok meghatározása azonosítani kell a projekt kockázati tényezőit, és azoktól függően alternatív stratégiákat kell tervezni
Kockázat becslése és csökkentése: – – –
minden egyes kockázati tényezőre vonatkozóan részletes elemzést kell végezni meg kell próbálni csökkenteni a kockázatot például, ha felmerül, hogy a követelmények nem megfelelőek, akkor célszerű fejleszteni egy prototípust
Szoftvermenedzsment
Soós Sándor
37
A spirális fejlesztés ciklusainak négy fázisa, folyt. ●
Fejlesztés és validálás: –
a kockázatok vizsgálatának eredményétől függően választani kell egy fejlesztési modellt, például ●
●
– ●
ha a felhasználói felületet érezzük kockázatosnak, akkor választhatjuk az evolúciós fejlesztést ha a biztonsági kockázatokat találtuk a legfontosabbnak, akkor használjuk a formális transzformációkat
végezzük el a fejlesztést és ellenőrizzük a kész modult
Tervezés –
meg kell vizsgálni a projektet, és el kell dönteni, hogy folytassuk-e a következő ciklussal
Szoftvermenedzsment
Soós Sándor
38
A spirális fejlesztés értékelése ●
●
●
●
Más módszerekkel szemben kifejezetten számol a kockázati tényezőkkel Kockázat minden olyan dolog, ami elromolhat a projekt folyamán Ebben a modellben nincsenek kötelezően előírt fázisok, mint specifikáció, vagy tervezés Magába illeszthet bármilyen más módszertant, minden ciklusban eldöntjük, hogy ezt milyen módszerrel fejlesztjük ki
Szoftvermenedzsment
Soós Sándor
39
A szoftverfolyamat alapvető elemei ●
A következőkben megvizsgáljuk közelebbről a szoftverfolyamat alapvető szakaszait, amelyek valamilyen formában minden módszertannak részét képezik: – – – –
Szoftverspecifikáció Szoftvertervezés és implementáció Szoftvervalidáció Szoftverevolúció
Szoftvermenedzsment
Soós Sándor
40
Szoftverspecifikáció ● ● ●
●
Más szóval követelménytervezés Ezt a fázist, gyakran nem veszik elég komolyan Az itt elkövetett hibák, pontatlanságok alapvetően befolyásolják a projekt eredményét A követelménytervezés eredménye a követelménydokumentum
Szoftvermenedzsment
Soós Sándor
41
A követelménytervezés folyamata
Szoftvermenedzsment
Soós Sándor
42
A követelmények tervezésének négy fázisa 1. Megvalósíthatósági tanulmány – – –
meg kell becsülni, hogy a felhasználók kívánságai kielégíthetők-e az adott körülmények között el kell dönteni, hogy a rendszer költséghatékony-e, megvalósítható-e az adott költségvetésből viszonylag gyorsan, hatékonyan el kell dönteni, hogy érdemes-e belefogni a projektbe
Szoftvermenedzsment
Soós Sándor
43
A követelmények tervezésének négy fázisa 2. Követelmények feltárása és elemzése – –
Tisztázni és dokumentálni kell, hogy milyen elvárásoknak kell megfelelnie a majdani rendszernek Eszközei: ●
● ●
a megrendelővel, potenciális felhasználókkal folytatott megbeszélések a jelenleg rendszer(ek) alapos tanulmányozása különböző rendszermodellek, prototípusok felállítása
Szoftvermenedzsment
Soós Sándor
44
A követelmények tervezésének négy fázisa 3. Követelményspecifikáció – –
az elemzés eredményéül kapott információkat egy egységes dokumentummá alakítjuk Tartalmilag és formailag két részre tagolódik: ●
●
felhasználói követelmények a megrendelők, felhasználók számára fogalmazzák meg a rendszerrel szemben fennálló absztrakt elvárásokat, ennek megfelelő formában és nyelvezetben kell készülnie rendszerkövetelmények a fejlesztők számára tartalmazzák a konkrét elvárásokat a rendszerrel szemben, tulajdonképpen megadjuk, hogy milyen funkciókkal kell rendelkeznie a rendszernek
Szoftvermenedzsment
Soós Sándor
45
A követelmények tervezésének négy fázisa 4. Követelményvalidáció – – ●
●
ennek keretében ellenőrizendő, hogy mennyire valósak, konzisztensek, és mennyire teljesek a követelmények fel kell tárni és ki kell javítani az esetleges hibákat
A folyamat végén a megrendelővel el kell fogadtatni, alá kell íratni a követelménydokumentumot Ennek alapján fognak dolgozni a fejlesztők, ha ebben hiba van, akkor a rendszer biztosan hibás lesz, ezért mindkét fél érdeke, hogy alapos munkával készüljön el, és mindkét fél elfogadja
Szoftvermenedzsment
Soós Sándor
46
Szoftvertervezés és implementáció ●
●
Nem más, mint a rendszerspecifikáció futtatható programmá történő konvertálása Mindig magába foglalja a rendszer megtervezését, és a programozást, de például az evolúciós megközelítés esetén a specifikáció finomítását és tartalmazhatja
Szoftvermenedzsment
Soós Sándor
47
Szoftvertervezés ●
●
●
Ki kell alakítani az elkészítendő rendszer szerkezetét, a komponensek közötti kapcsolatokat és az interfészeket Meg kell tervezni az adatok áramlási rendszerét a komponensek között A tervezés szinte soha nem egylépcsős folyamat, rendszerint többszörös iteráció és visszalépés után jutunk el a végeredményig.
Szoftvermenedzsment
Soós Sándor
48
A tervezési folyamat
Szoftvermenedzsment
Soós Sándor
49
A tervezési folyamat tevékenységei ●
Architekturális tervezés: –
●
Absztrakt specifikáció: –
●
meghatározzuk és dokumentáljuk a rendszert felépítő alrendszereket, és a köztük lévő kapcsolatokat minden alrendszerre megadjuk a szolgáltatások specifikációját, és a rájuk vonatkozó követelményeket
Interfész tervezése: – –
minden alrendszerre meg kell tervezni és dokumentálni kell a többi alrendszer felé nyújtott interfészét ennek olyan egyértelműnek kell lennie, hogy anélkül tudjuk használni a szolgáltatásokat, hogy foglalkoznunk kellene az alrendszer belsejével
Szoftvermenedzsment
Soós Sándor
50
A tervezési folyamat tevékenységei ●
Komponens tervezése: –
●
Adatszerkezet tervezése: –
●
meg kell tervezni az egyes szolgáltatásokat megvalósító komponenseket és azok interfészeit. meg kell tervezni a program által használt adatszerkezeteket
Algoritmus tervezése: –
meg kell tervezni a programban használatos algoritmusokat
Ez egy általános modell, a gyakorlatban ezek a lépések nagyon sokféleképpen variálhatók Szoftvermenedzsment
Soós Sándor
51
Tervezési módszerek ●
●
●
●
A gyakorlatban a tervezés legtöbbször egy ad hoc folyamat, nincs mögötte módszertan A tervező kiindulva a követelményekből elképzel és leír egy rendszert általában természetes nyelven, nem formálisan Ennek alapján megindul az implementáció, aminek során legtöbbször eltérnek a tervtől, és ezt már nem dokumentálják, így az elkészült rendszer és a terv jelentősen eltérhet egymástól Ez jelentősen megnehezíti a rendszer későbbi üzemeltetését, továbbfejlesztését
Szoftvermenedzsment
Soós Sándor
52
Tervezési módszerek ●
●
Az évek során többféle tervezési módszertant dolgoztak ki, amelyek különböző módokon formalizálják a tervezési folyamatot Strukturált tervezési módszertanok: – – –
●
Structured Design (Constantine, Yourdon, 1979) Structured System Analysis (Gane, Sarson, 1979) Jackson System Development (Jackson, 1983)
Objektumorientált tervezési módszertanok: – – – – –
Robinson, 1992 Booch, 1994 Raumbaugh és mások, 1991 Booch és mások, 1999 Raumbaugh és mások, 1999a, 1999b
Szoftvermenedzsment
Soós Sándor
53
Strukturált tervezési módszertanok ●
● ● ●
Különböző, legtöbbször grafikus rendszermodelleket tartalmaznak Szabványos jelölésrendszereket alakítottak ki Szabványos tervezési dokumentumokat határoznak meg Különböző CASE eszközöket is kialakítottak ezek támogatására –
●
●
CASE: Computer Aided Software Engineering
A különböző módszertanok a hasonlóság mellett kisebb módosításokkal specializálódtak bizonyos területekre Nincsen egyértelműen jobb, vagy rosszabb módszer
Szoftvermenedzsment
Soós Sándor
54
Strukturált tervezési módszertanok ●
A különböző módszertanok meghatároznak: – – – – –
tervezési folyamatmodellt jelölésrendszert a terv leírásához jelentésformátumokat szabályokat tervezési útmutatókat
Szoftvermenedzsment
Soós Sándor
55
Strukturált rendszermodellek ●
A különböző módszertanok a következő rendszermodellek közül támogatnak egyet, vagy többet: –
Adatfolyam modell ●
–
a rendszert különböző adattranszformációk segítségével modellezzük
Egyed-kapcsolat (ER-Entity-Relationship) modell ●
különböző egyedek és köztük lévő kapcsolatok leírására szolgál. Az ER-modellek az adatbázis-szerkezetek leírásának modelljei is.
Szoftvermenedzsment
Soós Sándor
56
Strukturált rendszermodellek ●
Folytatás –
Strukturált modell ●
–
Objektumorientált módszerek ●
●
a rendszer komponenseit és a köztük lévő kölcsönhatásokat dokumentálja a rendszer öröklődési modelljét tartalmazzák, modellezik a statikus és dinamikus kapcsolatokat az objektumok között, és az objektumok együttműködését
Egyes módszerek más rendszermodelleket is használnak –
pl. állapotátmenet-diagrammok, egyed-élettartam mátrixok, stb.
Szoftvermenedzsment
Soós Sándor
57
Programozás és nyomkövetés ●
●
●
●
●
A megtervezett rendszer elkészítése, és az esetleges hibák megkeresése, kijavítása Bizonyos részeit CASE eszközökkel is lehet generálni A programozás még ma is meglehetősen személyes tevékenység, ahány programozó, annyi stílusban dolgozik A programozás közben folyamatosan teszteljük a kódot, megkeressük a hibákat, és kijavítjuk őket Ezt nevezzük nyomkövetésnek, belövésnek
Szoftvermenedzsment
Soós Sándor
58
Debugger ●
●
Programozói segédeszköz a programhibák felderítésére, és kijavítására Legfontosabb funkciói: – – – – – – –
a program soronkénti végrehajtása töréspontok kezelése, feltételes töréspontok a változók értékének figyelése, módosítása futás közben a memória tartalmának figyelemmel kísérése assembly szintű nyomkövetés a processzor regisztereinek figyelése, módosítása a hívási verem (call stack) megfigyelése
Szoftvermenedzsment
Soós Sándor
59
Szoftvervalidáció ● ●
●
●
Verifikáció és validáció Megvizsgálandó, hogy az elkészült rendszer megfelel-e a specifikációnak Az implementáció teljes ideje alatt folyamatosan folyik, de a rendszer elkészülte után feltétlenül szükség van alapos tesztelésre Egy összetett rendszer tesztelését alaposan meg kell tervezni, és részletekben kell elvégezni
Szoftvermenedzsment
Soós Sándor
60
A tesztelési folyamat
Szoftvermenedzsment
Soós Sándor
61
A tesztelési folyamat szakaszai ●
Egység tesztelése –
●
Modul tesztelése – –
●
minden egyes komponenst önmagában tesztelni kell, és el kell érni, hogy hibátlan legyen a modul egymással összefüggő komponensek gyűjteménye ezeket a többi modultól függetlenül lehet tesztelni
Alrendszerek tesztelése –
az alrendszert alkotó modulok tesztjeinek összessége, kiegészítve a köztük lévő kapcsolatok, az interfészek tesztelésével
Szoftvermenedzsment
Soós Sándor
62
A tesztelési folyamat szakaszai ●
Rendszerek tesztelése – –
–
a teljes rendszer tesztelése, különös tekintettel az alrendszerek kapcsolódásainak vizsgálatára a rendszerhibák legnagyobb része az alrendszerek kölcsönhatásaiból származik, ezeket a hibákat csak a rendszer tesztelése során lehet felderíteni ezen a szinten kell megvizsgálni, hogy a rendszer teljesíti-e a specifikációban meghatározott funkcionális és nem funkcionális követelményeket
Szoftvermenedzsment
Soós Sándor
63
A tesztelési folyamat szakaszai ●
Átvételi tesztelés – – – –
a tesztelés legutolsó fázisa a rendszer használatbavétele előtt ekkor már a megrendelő saját adataival folyik a tesztelés szerencsés, ha a megrendelő is részt vesz benne ekkor derülhetnek ki a követelménytervezés során elkövetett hibák, hogy a rendszer nem felel meg a felhasználó elvárásainak, vagy a rendszer teljesítménye elfogadhatatlan
Szoftvermenedzsment
Soós Sándor
64
Alfa és béta tesztelés ● ●
●
●
● ●
Az átvételi tesztet szokás alfa tesztelés-nek hívni Amikor egy szoftvertermék dobozos termékként kerül piacra, akkor szokás a béta teszt-nek nevezett eljárást használni A béta teszt során a potenciális felhasználók egy részéhez juttatják el a programot, akik valós, éles körülmények között kezdik el használni a szoftvert, valamilyen szerződés keretében Tapasztalataikról beszámolnak a fejlesztőknek, akik ezeket felhasználják a rendszer javítására Az elkészülő új verziót egy újabb béta tesztre bocsátják Ez ismétlődik amíg a rendszer minősége el nem éri a kívánt szintet
Szoftvermenedzsment
Soós Sándor
65
Szoftverevolúció ●
●
●
●
Miután egy hardver eszköz gyártása elkezdődik, bármilyen változtatás szinte lehetetlen, illetve nagyon költséges A szoftver esetében azonban a fejlesztés (gyártás) alatt bármikor elvégezhető bármilyen módosítás Sőt az sem lehetetlen, hogy a felhasználónál lévő szoftveren hajtsunk végre módosításokat Ezért van értelme szoftverevolúcióról beszélni
Szoftvermenedzsment
Soós Sándor
66
Szoftverevolúció
● ●
Ez a korszerű felfogás a szoftverevolúcióról A szoftverrendszerek egész életciklusuk alatt változhatnak, fejlődhetnek
Szoftvermenedzsment
Soós Sándor
67
Rational Unified Process (RUP) ●
●
● ●
egy modern folyamatmodell, az UML-ből származik hibrid modell, mindegyik általános modellből tartalmaz elemeket támogatja az iterációt míg a hagyományos modellek a folyamatoknak csak egy-egy nézetét támogatják, addig a RUP három perspektívával rendelkezik
Szoftvermenedzsment
Soós Sándor
68
A RUP perspektívái 1.dinamikus perspektíva
a modell fázisait mutatja
2.statikus perspektíva
a végrehajtandó folyamattevékenységeket mutatja
3.gyakorlati perspektíva
jól hasznosítható gyakorlatokat javasol a folyamat alatt
Szoftvermenedzsment
Soós Sándor
69
A RUP fázisai 1.Indítás
a projekt üzleti vonatkozásainak tisztázása. kik lesznek a projekt résztvevői, ezek kapcsolatai el kell dönteni, hogy elindítsuk-e a projektet
2.Előkészítés
célja a probléma megértése, a projektterv kifejlesztése a kulcsfontosságú kockázati tényezők azonosítása Eredménye:
a rendszerkövetelmények modellje (UML használati eset) architekturális leírás a szoftver fejlesztési terve
Szoftvermenedzsment
Soós Sándor
70
A RUP fázisai 2 3.Létrehozás
a rendszerterv elkészítése implementáció tesztelés
4.Átadás
a rendszer áttelepítése a fejlesztési környezetből a felhasználói környezetbe
Szoftvermenedzsment
Soós Sándor
71
A RUP fázisai
●
A RUP két szinten támogatja az iterációt, lásd az ábrán!
Szoftvermenedzsment
Soós Sándor
72
A RUP statikus munkafolyamatai
Szoftvermenedzsment
Soós Sándor
73
A RUP fázisok és folyamatok kapcsolata ●
●
●
A RUP fázisai és munkafolyamatai nincsenek kötelező érvénnyel egymáshoz rendelve Elméletileg bármely munkafolyamat bármelyik fázisban lehet aktív Persze ritkán történik Tesztelés az Indítás fázisban, de ez a tervező döntése
Szoftvermenedzsment
Soós Sándor
74
A RUP gyakorlati perspektívája ●
Fejlesszük a szoftvert iteratívan –
●
Kezeljük a követelményeket – –
●
tervezzük meg a rendszer inkremenseit a prioritások alapján, és hozzuk előre a magas prioritású tulajdonságokat dokumentáljuk a megrendelő követelményeit, és tartsuk mindig karban annak változásait elemezzük a változások rendszerre gyakorolt hatásait mielőtt elfogadnánk azokat
Használjunk komponens alapú architektúrákat –
a rendszert szervezzük komponensekbe
Szoftvermenedzsment
Soós Sándor
75
A RUP gyakorlati perspektívája 2 ●
Modellezzük a szoftver vizuálisan –
●
Ellenőrizzük a szoftverminőséget –
●
használjunk grafikus UML-modelleket a szoftver statikus és dinamikus nézeteihez bizonyosodjunk meg róla, hogy a szoftver megfelel a minőségi előírásoknak
Ellenőrizzük a szoftverváltoztatásokat –
menedzseljük a szoftverváltoztatásokat változtatáskezelési eszközökkel és konfigurációkezelési eljárásokkal
Szoftvermenedzsment
Soós Sándor
76
A RUP értékelése ●
●
A RUP nem alkalmas minden különböző típusú szoftver kifejlesztésére, de az általános folyamatok új generációjának tekinthető Legfontosabb újítása: – –
●
●
a fázisok és a munkafolyamatok szétválasztása az üzembeállítás beemelése a munkafolyamatok közé
A fázisok dinamikusak és konkrét célokkal rendelkeznek A munkafolyamatok statikusak és olyan technikai tevékenységeket írnak le, amelyek felhasználhatók az egész fejlesztés folyamán
Szoftvermenedzsment
Soós Sándor
77
Számítógéppel támogatott szoftvertervezés (CASE) ● ●
●
●
Computer-Aided Software Engineering (CASE) Olyan szoftverek együttese, amelyek a szoftverfolyamat egyes tevékenységeinek támogatására szolgálnak Ismerünk már ilyen eszközöket, soroljuk fel ezeket! Most megismerkedünk újabb típusokkal
Szoftvermenedzsment
Soós Sándor
78
Néhány példa CASE eszközök használatára ● ● ●
● ● ●
grafikus rendszermodellek fejlesztése a tervek megértését segítő adatszótárak kezelése felhasználói interfész tervezése és implementálása program belövés támogatása, debuggerek kódgenerálás automatikus fordítás egyik programnyelvről egy másikra, pl. COBOL
Szoftvermenedzsment
Soós Sándor
79
A CASE technológiák elterjedése ●
●
●
●
Napjainkban a szoftverfolyamat szinte minden fázisához léteznek CASE eszközök, legtöbbször a rutintevékenységeket támogatják Ennek hatására javult a szoftverek minősége, de ez kisebb mértékű. mint ahogyan kezdetben gondolták, egyes mérések szerint kb. 40%-os a javulás A CASE technológia kezdeti pártolói nagyságrendi javulást jósoltak Nem vált valóra az a várakozás sem, hogy a CASE lényegesen csökkenti a szoftverfolyamat költségeit
Szoftvermenedzsment
Soós Sándor
80
A CASE technológiák korlátai ●
Miért nem következhetett be a várt nagyságrendi változás? –
–
●
a szoftvertervezés tervezői tevékenység, ami kreatív gondolkodáson alapszik, a CASE eszközök azonban ebben nem sokat tudnak segíteni, azok csak a rutintevékenységeket tudják támogatni, csak kisebb mértékben tudnak a mesterséges intelligencia eszközeivel segíteni a szoftvertervezés nagyrészt csoportos tevékenység, állandó kommunikációt, egyeztetést igényel, ebben is csak kisebb segítséget tud nyújtani a számítógép
Párhuzam: gépi fordítás
Szoftvermenedzsment
Soós Sándor
81
A CASE eszközök osztályozása ●
Három szempontból fogjuk osztályozni a CASEeszközöket: –
funkcionális szempontból: ●
–
folyamatnézőpontból: ●
–
a CASE eszközök funkciói szerint milyen folyamatot támogatnak
integrációs nézőpontból: ●
hogyan vannak integrált egységekbe szervezve
Szoftvermenedzsment
Soós Sándor
82
Funkcionális osztályozás
Szoftvermenedzsment
Soós Sándor
83
Folyamatközpontú osztályozás
Szoftvermenedzsment
Soós Sándor
84
Integrációs szempontú osztályozás ●
Eszközök –
●
Eszközkészletek – –
●
az egyéni folyamatlépéseket támogatják, például fordítóprogram, tesztelőeszközök, stb. a munkafolyamat egy-egy fázisát támogatják, például a specifikációt, tervezést, stb. ezek legtöbbször a fenti eszközökből összeállított csomagok, készletek
Környezetek –
a szoftverfolyamat több, lehetőleg minden részét támogatják egy integrált keretben
Szoftvermenedzsment
Soós Sándor
85
CASE eszközök, eszközkészletek, környezetek osztályozása
Szoftvermenedzsment
Soós Sándor
86
