Szoftver tervezés és minısítés

Szoftver tervezés és minısítés

Szoftver tervezés és minısítés 1/a) Ismertesse és értékelje az alapvetı szoftvertervezési megközelítéseket (filozófiákat)! - adatfolyam-orientált • A szoftver struktúráját az adatok áramlása alapján tervezi (Constantine, Yourdon, 1979) (Lényegében a funkcionális és az adatstruktúrán alapuló tervezés ötvözete. Elemei sok újabb módszerben megtalálhatók. • Lépései: – Adatáramlási diagram elkészítése, (elılrıl-hátra, vagy hátulról-elıre) – Szoftver szerkezeti diagram (az elızı alapján) – Iteráció.. • Használható: – Elsısorban szekvenciális adatfeldolgozó rendszerek, vagy szekvenciális vezérlı rendszerek tervezésére. – Kis- és nagy rendszerekre egyaránt alkalmazható. •

• • •

Célja: Megérteni a problémát és kerülni azokat a szerkezeteket és utasításokat, amelyekkel könnyő hibát elkövetni, vagy nehezebb megértésük. Kezdete a 60-as évek második fele (Dijkstra) Adatfolyam orientált megközelítés, a fı ábrázolási módja a Data Flow Diagram. Közös jellemzık: – A probléma leképezése terv/modell reprezentációra – Jelölések alkalmazása – Heurisztikus módszerek alkalmazása – Minıségi szempontok figyelembe vétele

– Ha nem soros a feldolgozás, nem igazán alkalmazható. – Ha egy programnak többféle, alapjában eltérı szerkezető input adatszerkezetet kell feldolgoznia – szerkezeti ellentmondás bonyolulttá válik a program, köztes állományokat kell tervezni és alkalmazni (teljesítmény probléma). – Egyszerő adatszerkezeteken is szükség lehet bonyolult feldolgozásokra, ennek tervezésében nem segít - objektumorientált Lásd 15/a - folyamatorientált • A folyamatmodellel lényegében az információ áramlását mutatjuk be. • Meghatározzuk – Milyen információ/honnan érkezik inputok – Ki fogja felhasználni az információt szerepek – Mit tesznek, mire van szükségük a szereplıknek feladatok – Mikor van rá szükség, mennyi ideig tart idızítés – Milyen utat jár be az információ a következı tevékenységhez döntések – Hogyan jut el az információ az egyik helyrıl a másikra rendszerek o A Dijkstra féle hierarchikus programozás és az SSADM az elsı csoportba tartozik, o A Jackson System Design a másodikba és részben a harmadikba sorolható

- adatstruktúra-orientált (pl Jackson:) • Jackson Structured Programming (JSP) (1975) • Adatszerkezet alapú tervezés: – A program szerkezete legyen összhangban az általa kezelt adatok struktúrájával. • Az input és output adatok szerkezetébıl indul ki, fa struktúrában modellezi azokat. • A programot az adatokon végzendı mőveletek szerkezetével ábrázolja. • A mőveleteket a program struktúrájára képezi le. • A fizikai és logikai adatszerkezet különbözhet egymástól: • A fizikai adatszerkezet a tényleges szervezıdést ábrázolja • A logikai szerkezetben a feldolgozás szempontjából lényeges adatszerkezetet mutatja. • Elınyök: – Világos, egyértelmő, a tervezéskor a program szerkezetét az adatok struktúrájához igazítja. – Rekordszerkezető input fájlok soros feldolgozására a legalkalmasabb. – Az egyes lépések eredménye kézzelfogható. • Hátrányok: – Bonyolult adatszerkezet(ek) esetén nehézkes.

1/b) Mi az információ rejtés célja? Milyen információkat rejtünk el? Hogyan határozzuk meg az elrejthetı információkat? • Az információ elrejtését már a strukturált tervezés is alkalmazta (black box), az objektum orientált tervezésnek pedig egyik legfontosabb eszköze. • Minden csomag, osztály, vagy rutin elrejtheti a tervezési és implementációs megoldásokat, amelyek módosulhatnak (pl. adattípusok implementálásának módja, fájltípusok, stb.) • Az elrejtés jelentısen csökkentheti a bonyolultságot : – Egy osztály interfészei úgy tervezhetık, hogy a belvilág nagy része rejtett marad (jéghegy effektus – 12% látható). – Egyszerőbbé válik a módosítás. • Vannak azonban veszélyei: – A rejtett részletekben nehezebb megtalálni a hibákat. • Az elrejtést kétféle céllal alkalmazhatjuk: – A bonyolultság csökkentésére Nem kell foglalkozni olyan részletekkel, amelyek az adott szinten lényegtelenek (pl. bonyolult adattípusok, fájlstruktúrák, stb.) – A várhatóan gyakran változó részek szeparálására A tervezéskor gyakran elıre tudható, mely részletek fognak többször változni, ezeket célszerő elrejteni, és csak interfészeken keresztül tenni hozzáférhetıvé. Így a módosítások egy szők körben végrehajthatók.

1. oldal

2. oldal


Szoftver tervezés és minısítés •

•

•

Elrejtés korlátai: Általában mentális okok (pl. más technikákból származó megszokások) – A „szertelen” információ-megosztás • Pl. Globális információ lehet az alkalmazottak max. száma, amire a programban sokfelé szükség lehet, de globális adatként használva bonyolult a változtatása. • Felhasználói interakciók kezelése (GUI, parancssoros, stb.) – Körkörös függıségek • Pl. Több osztály rutinjai körbehívják egymást – nehéz tesztelni. – Egy osztály adatának globális adatként való használata • A globális változóról nem lehet tudni, hogy más mikor, hogyan, mire használja. Elkerülhetı, ha csak egy osztály néhány rutinja fér hozzá. – Teljesítmény megfontolások • A teljesítmény csökkenésétıl való félelem az architektúrális tervezés, vagy a kódolás szintjén. (Aggódjunk majd a rendszerteszt idején. Egy moduláris rendszert egyszerőbb módosítani.) Elrejtés elınyei: – Az információ elrejtése azon kevés elméletek közé tartozik, amelyek igazolódtak a gyakorlatban (egyaránt alapvetı technikája a strukturált- és az OO módszereknek) – Tipikus példa: ID Type, vagy int – „Miért kínlódjunk egy osztály létrehozásával, mikor elég lenne egy integer is?” – Pedig: – Ha úgy döntünk, hogy elrejtjük, egy következı szintre halasztottuk a döntést, a tervezés egy olyan fázisára, amikor többet tudunk a rendszerrıl. (És még mindig lehet, hogy egyszerő típusdeklarációval fogjuk megoldani.) – Osztályok interfészének tervezésekor mindig tegyük fel a kérdést: mit rejthetünk el? (és nem azt, hogy mit kell elrejteni) A cél: a várhatóan instabil részek meghatározása

2/a) Milyen alapvetı különbségeket tud felsorolni a hagyományos mérnöki tervezés és a szoftvertervezés között? - mérnöki tervezés: - kialakultak módszerek, melyek alkalmasak a tervek összehonlítására, ill. a költségek becslésére - hiba esetén az épületet lebontják, újratervezik és újraépítik - szoftvertervezés: - nincsenek megbízható módszerek tervezéshez, modellezéshez, költségek becsléséhez - nincsenek szabványosított építıelemek - hiba esetén újraindítják a rendszert, az esetleges esetleírásokat elküldik a fejlesztıknek 2/b) •

Mire szolgál az öröklıdés? Miért alkalmazzuk a szoftvertervezésben? Egyszerősíti a tervezést

3. oldal

•

•

•

A szoftver tervezésekor gyakran találunk olyan objektumokat, amelyek csak néhány részletben különböznek egymástól (pl. bérszámfejtés állandó és megbízásos alkalmazott esetén) A szuperosztály és a származtatott osztályok alkalmazásával a programozás egyszerősíthetı. (A feldolgozás nagy része az általános adatokkal foglalkozik – név, cím, beosztás, végzettség, stb. – ritkábban kell a specializált osztályokkal foglalkozni.) Az öröklıdés az absztrakció eszköze, alkalmazása csökkenti a komplexitást. (Általános rutinok foglalkozhatnak az általános tulajdonságokkal és speciális rutinok végezhetnek mőveletet a specifikus adatokon.)

2/c) Mi a CRC tervezés lényege? Miben segíti az objektumközpontú tervezést? - célja: segíteni (formalizálni) az osztályok meghatározását és rendszerezését - Class: osztályok és objektumok meghatározása (alapvetı tulajdonságok) - Responsibilities: osztályok és objektumok szerepének, viselkedésének meghatározása (a nyújtott szolgáltatások leírása) - Collaborators: az együttmőködı osztályok meghatározása (típusai: része, ismeri, függ tıle)

3/a) Soroljon fel néhány szoftvertervezési módszert, amelyet az elmúlt harminc évben kidolgoztak, és értékelje azokat. - 70-es évek vége: adatorientált programozás - a program szerkezetét az adatok szerkezete határozza meg - 80-as évek: objektumorientált programozás - célja a bonyolultság kordában tartása - az adat és a funkció közös modellezése - 90-es évek: Internet elterjedése - OOD&P rohamos fejlıdése - növekvı bonyolultság - egységes jelölésrendszer kell: UML - ma: - agilis programozás - folyamatmodellezés - automatikus kódgenerálás 3/b) Ismertesse a tervezési minták lényegét! Milyen céllal dolgozták ki ıket? - tervezési minta: olyan statikus vagy dinamikus struktúra, melyet egy adott szakterület alkalmazásfejlesztési feladataiban már sikerrel alkalmaztak - az architektúratervezést támogatják - minıség javítása, fejlesztési idı csökkentése, újrafelhasználás lehetısége - meghatározott, gyakran elıforduló problémákra kínálnak megoldásokat Csoportosításuk: - architektúrális minták: - a rendszer alapvetı struktúráját írják le - definiálják az alrendszereket, azok felelısségét és kapcsolatát - tervezési minták: - alrendszereken belül használhatók - programozási nyelvtıl függetlenek (bár megvalósításuk függ a nyelvtıl) - idiómák: - alacsony szintő, speciális minták

4. oldal

Szoftver tervezés és minısítés - kötıdnek egy adott programozási nyelvhez - gyakran felmerülı problémák nyelvhez kötött megoldásai

4/a) Ismertesse az „agilis” szoftverfejlesztési módszerek fıbb közös törekvéseit! (Az "Agile Manifesto” négy fı célkitőzése) - SW folyamatok és eszközök HELYETT egyének és kapcsolataik - rengeteg dokumentáció HELYETT mőködı szoftver - merev szerzıdések HELYETT felhasználói együttmőködés - szigorú tervek követése HELYETT a változó igényekre való folyamatos reagálás 4/b) Mire szolgál a COCOMO módszer? Milyen modelleket alkalmaz? /* A szoftver metrikák módszerei osztályozhatók a mérés (vagy becslés) célja szerint: A szoftver méretének becslésére: - COCOMO - Funkciópont - Objektumpont A bonyolultság becslésére: - Halstead módszere: Computer Science - McCabe: ciklomatikus komplexitás Tervezéri metrikák: - Architerktúrális tervezési metrika - Struktúrális bonyolultság - Adat komplexitás - Öröklési fa mélysége */ COCOMO (COnstructive COst MOdel. Elsı verzió 1981-ben született.) - A COCOMO empirikus modell, a szoftverfejlesztési projektek tapasztalataira épül. - Nem kapcsolódik egyetlen gyártóhoz sem. - A kezdeti változatok vízesés modell alkalmazását feltételezték, meg hogy 0-ról indul a projekt. - A COCOMO-II már egy sor almodellt tartalmaz, hogy a különbözı fejlesztési fázisokban és különbözı folyamatmodellekhez alkalmazható legyen: - Alkalmazás kompozíciós modell - Arra az esetre, a a szoftvert létezı részekbıl állítják össze - Kezdeti tervezési modell - Arra az idıszakra, mikor a követelmények már rendelkezésre állnak, de a tervezés még nem kezdıdött el. - Újrafelhasználási modell - Az újrafelhasználható komponenseket integráló fejlesztés számára. - Poszt-architektúra modell - Arra az idıszakra, mikor az architektúra terv már elkészült és a renszerrıl több információ áll rendelkezésre COCOMO-II - Projekttervezés - Az algoritmikus költségmodellek alapján kiválasztható a fejlesztésre legalkalmasabb stratégia. - Az erıforrásigény mellett a napráti ütemezést is el kell végezni

5. oldal

Szoftver tervezés és minısítés - !!! a COCOMO szerint a fejlesztés idıtartama nem függ a projektben dolgozók számától !!! A COCOMO-t azok a programfejlesztı szervezetek használják, amelyek - nagy alkalmazásokat fejlesztenek - egyedi igényekre egyedi szoftvereket dolgoznak ki - rendszerintegrátorok, akik nagy és sok újrafelhasználható modult, rendszert integrálnak. Mivel a COCOMO heurisztikus modelleket használ, a korrekciós tényezıket a konkrét fejlesztı szervezetnél győjtött adatok alapján kell kijelölni. (ami suxor)

5/a) Ismertesse a dekompozíció célját, lényegét és fıbb lépéseit az objektumközpontú tervezésben. - részekre bontás - célja az átláthatóság, karbantarthatóság növelése - általában: - kiválasztjuk a feladat egy részét (elıször a teljes feladatot) - ezt felosztjuk két vagy több részre - a kisebb részek közti interakciókat meghatározzuk - ezt a 3 lépést ismételjük, amíg el nem érünk a kívánt részletességhez - OO: - a rendszer modulokra bontása (maximális koházió, minimális csatolás) - modulok közti kapcsolatok meghatározása - függések: öröklıdés, aggregáció - kommunikáció: globális változók, paraméteres hívások, üzenetek - modulok funkcióinak meghatározása - modulok közti interfészek meghatározása 5/b) Milyen módszert alkalmaznak a szoftverfejlesztı szervezet képességeinek minısítésére? - CMM - Capability Maturity Model Lásd 7/b - BOOTSTRAP Lásd 8/b SPICE • A SPICE az ISO folyamat modellje és minısítési eljárása. • A folyamatok minısítése egy kétdimenziós modell alapján történik: – Folyamat dimenzió: Process Reference Model (PRM) amely a folyamatokat céljuk és eredményeik alapján írja le, – Képesség dimenzió: Hat képességi szintet határoz meg, amelyek mindegyikéhez attribútumokat rendel. • A SPICE folyamat referenciamodelljei az alábbi területekre készültek el (vagy kidolgozás alatt állnak): – Szoftver életciklus folyamatok – ISO/IEC 12207 – Rendszer életciklus folyamatok – ISO/IEC 15288

6. oldal


•

– Emberközpontú életciklus folyamatok – ISO 18529 – Komponens alapú fejlesztési folyamatok – OOSPICE projekt – IT szolgáltatás-menedzsment folyamatok – SPICE User Group – Minıségkezelı rendszer folyamatok – SPICE for 9000 – Automotive beágyazott szoftver – SPICE User Group – Egészségügyi eszközök szoftverjei – Medi SPICE kezdeményezés A SPICE és a CMM összehasonlítása: – Amíg a CMM integrált, a szervezet egészére kiterjed, a SPICE az egyes folyamatok különálló elemzésére és minısítésére is alkalmas (pl. projektvezetés, vagy konfigurációkezelés) – A SPICE adatgyőjtési módszere jobb, mint a CMM-ben alkalmazott (jobban automatizálható) – A CMM nagy szervezetek minısítésére alkalmas, bár kis szervezetek számára készült változatai is vannak. A SPICE kidolgozásakor a kis/közepes szoftver szervezetek igényeit és lehetıségeit is figyelembe vették. (A SW fejlesztı cégek 70-80 százaléka 20-30 fıs.) – A SPICE nem jelöl ki prioritásokat a szervezetfejlesztésben, mint a CMM, csak az utat jelöli meg. Ez rugalmasabbá teszi a különbözı jellegő szervezetek eltérı prioritásaihoz való alkalmazásban.

Szoftver tervezés és minısítés - nagy rendszer fejlıdését jellemzıinek feljıdése, és nem vezetési döntések irányítják - a fejlıdés csaknem állandó - új funkciók viszonylag ritkán és azonos mértékben kerülnek be - a törvények általában csak a nagy rendszerekre vonatkoznak 6/b) Mi a szoftver becslés és mérés célja? - A szoftverfejlesztéssel foglalkozó szervezeteknek, csoportoknak szüksége van olyan adatokra, amelyek alapján megbecsülhetik egy konkrét fejlesztés erıforrásigényét és várható idıtartamát. - Ezek az infók fontosak a szervezet mőködéséhez: tervezés, szerzıdéskötés, képzés, stb. - A mérések segítséget adhetnak a különbözı technológiák és fejlesztési folyamatok (modellek) közti választáshoz is. (- kevés módszer, szabvány készült) (- A paraméterek mérhetısége: számszerősíthetı/nem számszerősíthetı, objektív/szubjektív) Metrikák: - A szoftver metrikák közé bármilyen jellemzı mérése hozzátartozik, amely numerikusan jellemzi: - a terméket (a szoftver rendszer, dokumentációk, stb.) vagy - a szoftverfolyamatot - Ilyenek lehetnek: - Kódsorok száma (LOC - Lines of Code) - Fog index (wtf?) - Ciklomatikus komplexitás - Funkciók jellemzıi (inputok, mőveletek, outputok, fájlok, stb.)

7/a) Ismertesse azokat a programozási szerkezeteket, illetve elemeket, amelyek alkalmazása növelheti a hibák számát a programokban! - lebegıpontos számok (összehasonlítás) - pointerek - párhuzamosság - megszakítások - öröklıdés - álnevek használata

6/a) Mire vonatkoznak Lehmann törvényei? Ismertesse a Lehmann törvények lényegét. - a törvények a szoftver változásának okait és következményeit foglalják össze: - a szoftver változtatása elkerülhetetlen - a változtatás növeli a bonyolultságot

7. oldal

7/b) Ismertesse a Capability Maturity Model célját és lényegét. - a szervezet folyamatainak alkalmasságát méri, osztályozza és értékeli. /* A nagy megrendelık elvárják a szoftverfejlesztı szervezettıl, hogy bizonyítsa alkalmasságát a nagy projektek minıségi végrehajtására. Ezért a CMM modell alapján független szakértık minısítik a fejlesztı szervezeteket, tanúsítják felkészültségüket.*/ - A CMM modell szintjei: 1. Kezdeti

8. oldal

Szoftver tervezés és minısítés - Nincsenek hatékony vezetési eljárások, vagy nem alkalmazzák azokat következetesen. 2. Ismételhetı - A vezetési, minıség-biztosítási és változáskezelési eljárásokat azonos típusú projektekben ismételve, a szervezet sikeres lehet (de a siker egyéni teljesítményektıl függ). 3. Meghatározott - A folyamatokat már definiálták, de a vezetési folyamatok még nem tudják azokat következetesen, maradéktalanul biztosítani. 4. Menedzselt - Már vannak definiált és bevezetett folyamatok, de azok folyamatos fejlesztése még nem biztosított. 5. Optimalizált - A folyamatok állanó fejlesztése definiált és biztosított.

Szoftver tervezés és minısítés 9/b)

Hogyan használható az UML jelölésrendszere üzleti folyamatok modellezésére? Milyen elınnyel jár az UML alkalmazása az üzleti- és a szoftvertervezésben? - az UML diagramok alkalmazásának célja magas szintő üzleti modellek készítése, melyek a követelményspecifikációban az üzleti struktúrát és a szervezetet ábrázolják Lásd még 11/a -> UML

10/a) Milyen a virtuális gép architektúra? Rajzoljon példát a nyílt és a zárt architektúrára. - a szoftver architektúra virtuális gépekre bontható - csökken a bonyolultság - virtuális gép: attribútumokat és mőveleteket szolgáltat, szolgáltatásokon keresztül kapcsolódik az alacsonyabb vagy magasabb szintő VG-ekhez - zárt architektúra: a VG csak alacsonyabb szintekrıl hívhat mőveleteket - jobb karbantarthatóság, hordozhatóság

8/a) Melyek az Extrém Programozás (XP) alapelvei és fı célkitőzései? Milyen gyakorlati módszereket használ ezek elérésére? Lásd 11/b 8/b) Mi a BOOTSTRAP modell? Milyen kapcsolata van a CMM modellel? • Európai fejlesztés, az EU ESPRIT projekt keretében dolgozták ki (elsı verzióját a SEI CMM modellekkel egyidıben, a 90-es évek elején), sok SW fejlesztési projekt tapasztalatai alapján. • Elsısorban a kis/közepes SW fejlesztı cégek, vagy nagyvállalatok szoftver csoportjai folyamatainak javítására, minısítésére használható. • A BOOTSTRAP Institute feladata a a modellek folyamatos karbantartása, korszerősítése. • A BOOTSTRAP új, 3.0 verziója már figyelembe veszi az ISO szoftverfolyamat mérésére és fejlesztésére szolgáló SPICE módszertant (ISO 12207), a kettıt közelítve egymáshoz. • A BOOTSTRAP folyamatokat és képességi szinteket definiál: • Képességi szintek (hasonlóan a CMM-hez) • Level 0 : Incomplete Process • Level 1 : Performed Process • Level 2 : Managed Process • Level 3 : Established Process • Level 4 : Predictable Process • Level 5 : Optimising Process • A minısítés kidolgozott kérdıívek alapján történik, minden kérdésre négy szintő válasz adható (nem, részben, nagyrészt, teljesen). A BOOTSTRAP Institute egy központi adatbázisban tárolja a minısítések eredményeit

9/a) Mi az alapvetı különbség a strukturált és az objektumalapú tervezés között? - a strukturált tervezés adatfolyam-orientált, míg az objektumalapú tervezés értelemszerően objektum-orientált filozófiát követ

9. oldal

- nyílt architektúra: a VG bármely rétegbıl igényelhet mőveletet - gyorsabb, gazdaságosabb

Lásd még 14/a

10. oldal


Szoftver tervezés és minısítés 10/b) Miért és mikor van szükség konfigurációkezelésre? Mely szoftver termékekre terjed ki? - egy változó szoftver rendszer termékeinek kezelésére szolgáló szabályok és eljárások - több szoftver verziót kell támogatni: - kiadott és még használt rendszerek - felhasználók számára testreszabott (eltérı funkcionalitású) rendszerek - fejlesztés alatt lévı rendszerek - különbözı platformon futó rendszerek - ezek koordinációt igényelnek - a konfigurációkezelés az egyes verziók közös és speciális termékeinek kézbentartását szabályozza: - specifikációk, tervek, programok, tesztadatok, kézikönyvek 11/a) Miért fontos az üzleti modellezés az informatikai rendszerek fejlesztésében? Ismertessen három üzleti modellezésre szolgáló nyelvet/jelölésrendszert! - az információs rendszer tervezıi technológiai szempontból közelítik a rendszert, nem azt látják, amit az üzletvitel megkíván a rendszertıl - az üzleti modell alkalmas arra, hogy az informatikai rendszerkövetelmények alapjául szolgáljon - OOA&D jó közös alap az üzleti és az informatikai modellezés számára Nyelvek: - IDEF (Icam DEFinition) nyelvcsalád - üzleti folyamat modellezı nyelvcsalád - ’95-ben jelent meg, azóta sok területet fed le (IDEF0-IDEF14) - IDEF0: what-to-do

- UML használati esetek - UML Activity Diagram: több aktor tevékenysége, melyeket függetlenül vagy egymással összefüggésben végeznek - UML szekvencia diagram - BPMN (Business Process Modelling Notation) - XML alapú, grafikus jelölésrendszer üzleti folyamatok ábrázolására - BPD-t (Business Process Diagram) definiál - 4 kategória: - folyamat-objektumok

- kapcsoló objektumok

- swimlanes

- artifacts

- IDEF1: a rendelkezésre álló információk és azok kezelésének leírása - IDEF2: szimulációs modellezés, what-if szituációk elemzése automatikusan - IDEF3: események logikai szekvenciáinak, a folyamatoknak OO leírása - IDEF4: objektum szemlélető tervezési módszer: osztályok, metódusok, öröklıdési diagramok - IDEF6-14: üzleti és szoftver modellezés egyéb feladatait támogató jelölésrendszerek - UML (Unified Modelling Language) - UML UseCase modell: üzleti folyamatok és funkcionális követelmények struktúrált leírása - UML Domain Model: üzletvitel átfogó ábrázolása - UML Üzleti Objektum Modell: szereplık, üzleti folyamatok és azok határoló elemeinek bemutatása 11. oldal

- a BPMN teljes folyamatokat, és részletes folyamat szegmenseket is képes modellezni - kétféle modelltípus: - kollaboratív B2B folyamatok modellje (publikus): két vagy több üzleti szereplı közti interakciók sorozata - belsı folyamatok modellje (privát): az egyes résztvevık belsı folyamatai 11/b) Melyek az extrém programozás alapelvei? - kommunikáció - visszacsatolás: a visszacsatolás alapján lehet áttekinteni a projekt elırehaladását

12. oldal

Szoftver tervezés és minısítés - egyszerőség: hagyjunk el mindent, amirıl nem bizonyítható, hogy feltétlen szükséges - bátorság: a folyamat résztvevıibe vetett bizalomhoz kell - gyakorlati módszerek: - páros programozás - teszt alapú tervezés: elıbb egységteszt, aztán kód - rendszer-újrastrukturálás - folyamatos integráció - közös tulajdonlás: a kódot bárki megváltoztathatja - kódolási szabályok betartása - 40 órás munkahét 11/c) Mi a különbség a termék- és a folyamatminıség között? - A szoftver metrikák általában összekapcsolódnak a minıségi kritériumokkal - A termék-metrikák jellemzıje, hogy a mért (vagy becsült) adatokból közvetlenül a szoftver minıségére vonatkozó következtetéseket vonnak le. - A folyamat-metrikák adataiból a szoftver termék minıségére csak áttételesen lehet következtetni (Ha a folyamat jó, az elıállított termék is jó lesz.) 12/a) Mi a különbség a nagy megbízhatóságú és a hibatőrı rendszerek között? Milyen hibatőrı szoftver architektúrákat ismer? - megbízhatóság: hibák bekövetkezésének valószínősége - hibatőrés: a rendszer hiba esetén is folytatja hibamentes mőködését - hibatőrı architektúrák: - N-version programming: -minden modult min. 3 csapat készít el, különbözı programnyelven, és ezek különbözı platformon futnak párhuzamosan - az eredményeket összehasonlítják - N-szeres erıforrásigény - statikus - recovery blocks: - a különbözı programokat egymás után hajtják végre, azonos hardveren - az eredményeket a rendszer teszteli ellenırzési pontokon, hiba esetén másik verziót futtat - újraindítási pontokat igényel - dinamikus 12/b) Mi a kapcsolat az üzleti modell és a szoftvermodell között? - az üzleti architektúra a szoftver pontos követelmény-specifikációjának alapja - az üzleti modell transzfomációja szoftver modellé nem egyszerő - az üzleti modellbıl nem minden osztály vagy objektum feleltethetı meg az informatikai osztályoknak - az üzleti modell segít: - annak eldöntésében, hogy milyen információs rendszert érdemes alkalmazni - a funkcionális és nem-funkcionális követelmények meghatározásában - meghatározni azokat az üzleti komponenseket, melyekre a szoftver komponensek alkalmazhatók Lásd még 11/a

13. oldal


13/a) Mi a lépésenkénti funkcionális felbontás? Írjon egy egyszerő példát a funkcionális felbontás alkalmazására. - egymást követı finomító lépések: taskok subtaskokra bontása  adatok struktúrájának finomítása - általában fa szerkezetként ábrázoljuk - a modularitás szintjét a környezet (programozási nyelv és számítógép) határozza meg - a program és az adatok struktúrájának ábrázolására alkalmazott jelölésrendszert következetesen kell használni, amíg lehet - minden lépés egy sor tervezési döntés eredménye, és minden lépésben mőveletek halmazaként írjuk le a programot - két tervezési stratégia: szintrıl szintre, vagy egy ágon végighaladva 13/b) Mi a funkciópont analízis? Milyen jellemzıket vesz figyelembe? - Célja az új szoftver kifejlesztéséhez, vagy meglévı szoftver karbantartásához szükséges idı és erıforrás szükséglet becslése és mérése (ezzel alapot ad a kölcségek becslésére) - Heurisztikus módszer, a szervezet korábbi fejlesztéseibıl összegyőjtött adatok alapján korrekciós tényezıket alkalmaz. - Az alábbi rendszerjellemzık számadatait használja: - Külsı inputok & outputok - Külsı interfészek - A rendszer által használt fájlok száma - Lekérdezések - Mindegyikhez egy súlyozási tényezı tartozik amelyre a módszer kezdeti értéket javasol, de a szervezet tapasztalatai alapján módosíthatja azt. - Alapvetıen a kódsorok számát számolja ki, ebbıl következtet az idıtartamra, erıforrás szükségletre. - Elosztott rendszererk becslésére/mérésére nem alkalmas. - A projekt mérete erısen befolyásolja az eredményt. - nem lehet automatizálni, mivel a súlyozási tényezıket egyénileg kell értékelni. - ha egy szervezetben kialakult az FPA használata, jó összehasonlítási alap lehet egyes ill. új projektek értékelésésre. 14/a) Mire szolgál a virtuális gép elmélete? Milyen többrétegő architektúrák tervezhetık vele? - teljesítmény megfontolások: - az N. szinten nem lehet megfelelı teljesítményt elérni, ha az alacsonyabb szintek nincsenek megfelelıen implementálva  gyakran szükséges a tervezési elvekkel ellentétesen implementálni a VG-ket - a VG-k szintjei közti függıségeket meg kell szőntetni, vagy minimalizálni kell - többrétegő architektúrák: - kliens-szerver - webszerver-alkalmazás szerver-adatbázis szerver Lásd még 10/a 14/b) Milyen módszert ismer a szoftver komplexitásának becslésére? - Hallstead módszer

14. oldal



- "Minden program jellemezhetı néhány számszerüsíthetı paraméter mérésével vagy becslésével." - Az egyik ilyen mérték a programszótár(n) - n=n1+n2 ahol n1 a különbözı operátorok, n2 az eltérı operandusok száma - program hossza(N) - N=N1+N2 ahol N1 az összes elıforduló, nem feltétlenül különbözı operátor, N2 az összes elıforduló operandus. - program terjedelme(V) - helyfoglalás jellemhıje: V=N log2 n(n1+n2) //sztem elég csak a mértékek nevét megjegyezni ;) - Ciklomatikus komplexitás - A program vezérlési gráfjából számítja a bonyolultságra jellemzı ciklomatikus komplexitást. blabla - A CC az alapvetı vezérlési útvonalak megadásával jól jellemzi a program, ill. részeinek bonyolultságát - független utak számát megadva, a szükséges tesztelés mértékét jellemzi - jellemzı a várható karbantartási igényekre is //CC=10 a powa modul méret, ami még kezelhetı

- átfogó modell kidolgozása - tulajdonságlista összeállítása - tervezés - ezek a projekt kezdetén - design by feature - build by feature - ezek minden iterációban - folyamatok taskokra vannak bontva - nagy és komplex, akár kritikus rendszerek fejlesztésére alkalmas - DSDM: Dynamic System Development Method - erıforrások és idı funckiókhoz való hozzárendelése HELYETT funckiók idıhöz és erıforrásokhoz való hozzárendelése - öt fázis: - megvalósíthatósági tanulmány - üzleti tanulmány - funcionális modell iterációja - inkrementumtervezés és –építés - implementáció - kis és nagyobb projektekre is alkalmas - fıleg üzleti rendszereknél - RUP: Rational Unified Process - 4 fázis: elıkészítés, kidolgozás, megvalósítás, átadás - ezeken belül munkafolyamatok: - üzleti modellezés, követelmény-elemzés, tervezés - implementáció, tesztelés, telepítés - konfigurációkezelés, projektvezetés, környezet kialakítása - a telepítés kivételével mind jelen van az összes fázisban

15/a) Ismertesse az OO analízis és tervezés folyamatát, alapvetı módszereit. - OO analízis - követelmények megismerése, rendszerezése - objektum modellek készítése - magas szintő modellek készítése - OO tervezés - absztrakt modellek kidolgozásával a tervek közelítése az analízis során kidolgozott tervekhez - architektúra dekompozíciója, objektumok finomítása - programozási nyelv, implementációs megoldások kiválasztása - folyamat: - alrendszer tervezés (csomagok) - osztály- és objektumtervezés (modulok) - interfésztervezés (modulok csatolása) - adatstruktúra- és algoritmustervezés (attribútumok, metódusok) Módszerek: - adat absztrakció - információ elrejtés - öröklıdés - dinamikus kötés - generikus szerkezet - kivételkezelés 15/b) Soroljon fel néhány (min 3) agilis módszert és jellemezze ıket. Ismertesse az eltérı és a közös jellemzıket. - FDD: Feature Driven Development - kis léptékő iterációk - öt fázis: 15. oldal

16/a) Milyen hibatőrı szoftver architektúrákat ismer? Ha több is van, röviden hasonlítsa össze ıket! Lásd 12/a 16/b) Mi a Service Oriented Architecture (SOA) lényege? Milyen hálózatos megoldás képezi a SOA alapját? - az OO komponens alapú fejlesztés hátránya, hogy szabványok híján nehéz az idegen forrásból származó komponenseket a saját rendszerbe integrálni - ehelyett a SOA szerint a kívánt funkciót a Web-en elérhetı szolgáltatásként veszik igénybe - a SOA lényege, hogy nem fejlesztik ki minden újabb alkalmazáshoz az azonos funkciókat, hanem az interneten keresztül, szolgáltatásként veszik azokat igénybe

- alapja a WebServices: - Interneten hozzáférhetı, azon keresztül hívható szolgáltatások - programozási nyelv- és platformfüggetlen - többé-kevésbé szabványosított architektúra (SOAP, WSDL, UDDI) - önleíró

16. oldal

Szoftver tervezés és minısítés

Recommend Documents