https://vik.wiki/api.php?action=feedcontributions&feedformat=atom&user=Halacs 2026-04-29T02:08:56Z Felhasználó közreműködései MediaWiki 1.43.8 https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175863 2014-01-20T20:12:59Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP (Quality Improvement Paradigm)'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának figyelése, mérésekkel. Annak meghatározása, hogy mely technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> ** A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> ** Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> *** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> *** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> *** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét, rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 20., 16:35 (UTC)<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175860 2014-01-20T19:54:24Z

<p>Halacs: /* 1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra: */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * '''ISO 9126:''' ''termék:'' definíció, minőségi attribútum, mérőszám (termék alapú)<br /> * '''Boehm:''' ''termék:'' definíció, minőségi attribútum, mérőszám (termék alapú)<br /> * '''McCall:''' ''termék:'' definíció, minőségi attribútum, mérőszám (termék alapú)<br /> * '''ISO 9000''': (folyamat alapú!)<br /> * '''ISO 9001:2000 (MSZ EN ISO 9001):''' ''termék:'' minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú!)<br /> * '''CMM (a.k.a. CMMI):''' ''termék:'' minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''SPICE:''' ''termék:'' folyamat minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú!)<br /> * '''ISO 15504:''' ''termék:'' inőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú!)<br /> * '''TSP''': ''termék:'' minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''PSP:''' ''termék:'' minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''PM módszertanok, People CMM, Weinberg:''' ''folyamat:'' definíció; ''erőforrás:'' definíció, minőségi attribútum, mérőszám; (folyamat alapú ?)<br /> * '''GQM:''' termék+folyamat+erőforás: mérőszám<br /> <br /> [[Fájl:szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png]]<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> A minőség nincs &quot;ingyen&quot; (megfelelőség költsége), de olcsóbb, mint a lehetséges alternatíva (nem megfelelőség költsége).<br /> <br /> '''CoQ = megfelelőség költsége + nemmegfelelőség költsége'''<br /> * megfelelőség költsége = megelőzés költsége + értékelés költsége (mennyit fektetünk abba, hogy a fejlesztésben ne kelljen javítások miatt “visszatérni”)<br /> ** Megelőzés:<br /> **: hibák megelőzésével kapcsolatos költségek:<br /> **: tervezés, dokumentálás, képzés, eszközök, eljárások és szabványok, minőségjavítási projektek, adatok gyűjtése ée elemzése, hibák okának elemzése, minőségi jelentések...<br /> ** Értékelés<br /> **: hibakereséssel kapcsolatos költségek:<br /> **: szemlék (rendszer, követelmény, tervezés, teszetlési terv), kódszemlézés, tesztelés (első alkalommal), auditok, CMM felmérés... <br /> * nemmegfelelőség költsége = belső hibák költsége + külső hibák költsége (mennyibe kerül “visszatérni” és javítani)<br /> ** Belső hibák költsége<br /> **: a rendszer átadása előtt megtalált hibákkal kapcsolatos költségek:<br /> **: újraírás (követelmények, tervek, modellek, kód, dokumentáció), hibajavítás miatti újratesztelés, folyamatokban jelentkező veszteségek (tesztelés miatti kiesés, átadandók változtatása, időbeli csúszások, költsége-túllépések…)<br /> ** Külső hibák költsége <br /> **: a rendszer átadása után megtalált hibákkal kapcsolatos költségek<br /> **: garancia, „apró” módosítások, sikertelen projektek, be nem tervezett verziók...<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 17., 17:11 (UTC)<br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175843 2014-01-20T16:40:07Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának figyelése, mérésekkel. Annak meghatározása, hogy mely technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> ** A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> ** Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> *** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> *** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> *** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét, rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 20., 16:35 (UTC)<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175842 2014-01-20T16:38:03Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának figyelése, mérésekkel. Annak meghatározása, hogy mely technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> ** A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> ** Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét, rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 20., 16:35 (UTC)<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175841 2014-01-20T16:37:17Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának figyelése, mérésekkel. Annak meghatározása, hogy mely technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> ** A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> ** Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 20., 16:35 (UTC)<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175840 2014-01-20T16:36:06Z

<p>Halacs: /* 5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának figyelése, mérésekkel. Annak meghatározása, hogy mely technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 20., 16:35 (UTC)<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175839 2014-01-20T16:35:44Z

<p>Halacs: </p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának figyelése, mérésekkel. Annak meghatározása, hogy mely technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 20., 16:35 (UTC)<br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175838 2014-01-20T16:33:50Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának figyelése, mérésekkel. Annak meghatározása, hogy mely technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175837 2014-01-20T16:32:56Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának figyelése, mérésekkel. Annak meghatározása, hogy mely technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175818 2014-01-20T11:38:26Z

<p>Halacs: /* 1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra: */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * '''ISO 9126:''' ''termék:'' definíció, minőségi attribútum, mérőszám (termék alapú !?!)<br /> * '''Boehm:''' ''termék:'' definíció, minőségi attribútum, mérőszám (termék alapú !?!)<br /> * '''McCall:''' ''termék:'' definíció, minőségi attribútum, mérőszám (termék alapú !?!)<br /> * '''ISO 9001:2000:''' ''termék:'' minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''CMM (a.k.a. CMMI):''' ''termék:'' minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''SPICE:''' ''termék:'' folyamat minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''ISO 15504:''' ''termék:'' inőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''TSP''': ''termék:'' minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''PSP:''' ''termék:'' minőségi attribútum, mérőszám; ''folyamat:'' definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * '''PM módszertanok, People CMM, Weinberg:''' ''folyamat:'' definíció; ''erőforrás:'' definíció, minőségi attribútum, mérőszám; (folyamat alapú ?)<br /> * '''GQM:''' termék+folyamat+erőforás: mérőszám<br /> <br /> [[Fájl:szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png]]<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> A minőség nincs &quot;ingyen&quot; (megfelelőség költsége), de olcsóbb, mint a lehetséges alternatíva (nem megfelelőség költsége).<br /> <br /> '''CoQ = megfelelőség költsége + nemmegfelelőség költsége'''<br /> * megfelelőség költsége = megelőzés költsége + értékelés költsége (mennyit fektetünk abba, hogy a fejlesztésben ne kelljen javítások miatt “visszatérni”)<br /> ** Megelőzés:<br /> **: hibák megelőzésével kapcsolatos költségek:<br /> **: tervezés, dokumentálás, képzés, eszközök, eljárások és szabványok, minőségjavítási projektek, adatok gyűjtése ée elemzése, hibák okának elemzése, minőségi jelentések...<br /> ** Értékelés<br /> **: hibakereséssel kapcsolatos költségek:<br /> **: szemlék (rendszer, követelmény, tervezés, teszetlési terv), kódszemlézés, tesztelés (első alkalommal), auditok, CMM felmérés... <br /> * nemmegfelelőség költsége = belső hibák költsége + külső hibák költsége (mennyibe kerül “visszatérni” és javítani)<br /> ** Belső hibák költsége<br /> **: a rendszer átadása előtt megtalált hibákkal kapcsolatos költségek:<br /> **: újraírás (követelmények, tervek, modellek, kód, dokumentáció), hibajavítás miatti újratesztelés, folyamatokban jelentkező veszteségek (tesztelés miatti kiesés, átadandók változtatása, időbeli csúszások, költsége-túllépések…)<br /> ** Külső hibák költsége <br /> **: a rendszer átadása után megtalált hibákkal kapcsolatos költségek<br /> **: garancia, „apró” módosítások, sikertelen projektek, be nem tervezett verziók...<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 17., 17:11 (UTC)<br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175817 2014-01-20T11:34:58Z

<p>Halacs: /* 1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra: */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * ISO 9126: termék: definíció, minőségi attribútum, mérőszám (termék alapú !?!)<br /> * Boehm: termék: definíció, minőségi attribútum, mérőszám (termék alapú !?!)<br /> * McCall: termék: definíció, minőségi attribútum, mérőszám (termék alapú !?!)<br /> * ISO 9001:2000: termék: minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * CMM (a.k.a. CMMI): minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * SPICE: folyamat minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * ISO 15504: minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * TSP: minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * PSP: minőségi attribútum, mérőszám; folyamat: definíció, minőségi attribútum, mérőszám (folyamat alapú !?!)<br /> * PM módszertanok, People CMM, Weinberg: folyamat: definíció;erőforrás: definíció, minőségi attribútum, mérőszám; (folyamat alapú ?)<br /> * GQM: termék+folyamat+erőforás: mérőszám<br /> <br /> [[Fájl:szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png]]<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> A minőség nincs &quot;ingyen&quot; (megfelelőség költsége), de olcsóbb, mint a lehetséges alternatíva (nem megfelelőség költsége).<br /> <br /> '''CoQ = megfelelőség költsége + nemmegfelelőség költsége'''<br /> * megfelelőség költsége = megelőzés költsége + értékelés költsége (mennyit fektetünk abba, hogy a fejlesztésben ne kelljen javítások miatt “visszatérni”)<br /> ** Megelőzés:<br /> **: hibák megelőzésével kapcsolatos költségek:<br /> **: tervezés, dokumentálás, képzés, eszközök, eljárások és szabványok, minőségjavítási projektek, adatok gyűjtése ée elemzése, hibák okának elemzése, minőségi jelentések...<br /> ** Értékelés<br /> **: hibakereséssel kapcsolatos költségek:<br /> **: szemlék (rendszer, követelmény, tervezés, teszetlési terv), kódszemlézés, tesztelés (első alkalommal), auditok, CMM felmérés... <br /> * nemmegfelelőség költsége = belső hibák költsége + külső hibák költsége (mennyibe kerül “visszatérni” és javítani)<br /> ** Belső hibák költsége<br /> **: a rendszer átadása előtt megtalált hibákkal kapcsolatos költségek:<br /> **: újraírás (követelmények, tervek, modellek, kód, dokumentáció), hibajavítás miatti újratesztelés, folyamatokban jelentkező veszteségek (tesztelés miatti kiesés, átadandók változtatása, időbeli csúszások, költsége-túllépések…)<br /> ** Külső hibák költsége <br /> **: a rendszer átadása után megtalált hibákkal kapcsolatos költségek<br /> **: garancia, „apró” módosítások, sikertelen projektek, be nem tervezett verziók...<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 17., 17:11 (UTC)<br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175816 2014-01-20T11:27:51Z

<p>Halacs: /* 4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> * dokumentumkezelés<br /> * bizonylatkezelés<br /> * belső auditok<br /> * nemmegfelelő termék kezelése<br /> * helyesbítő tevékenységek<br /> * megelőző tevékenységek<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175484 2014-01-17T18:43:10Z

<p>Halacs: /* 1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra: */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * ISO 9126 (Boehm, McCall): termék alapú; Product: metric, quality attribute, definition<br /> * ISO 9001:2000: folyamat alapú<br /> * CMM (a.k.a. CMMI): folyamat alapú<br /> * SPICE: folyamat alapú<br /> * ISO 15504:<br /> * TSP: folyamat alapú (?)<br /> * PSP: folyamat alapú (?)<br /> * GQM: Metric+Quality attribute: project management, technical process, product<br /> [[Fájl:szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png]]<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> A minőség nincs &quot;ingyen&quot; (megfelelőség költsége), de olcsóbb, mint a lehetséges alternatíva (nem megfelelőség költsége).<br /> <br /> '''CoQ = megfelelőség költsége + nemmegfelelőség költsége'''<br /> * megfelelőség költsége = megelőzés költsége + értékelés költsége (mennyit fektetünk abba, hogy a fejlesztésben ne kelljen javítások miatt “visszatérni”)<br /> ** Megelőzés:<br /> **: hibák megelőzésével kapcsolatos költségek:<br /> **: tervezés, dokumentálás, képzés, eszközök, eljárások és szabványok, minőségjavítási projektek, adatok gyűjtése ée elemzése, hibák okának elemzése, minőségi jelentések...<br /> ** Értékelés<br /> **: hibakereséssel kapcsolatos költségek:<br /> **: szemlék (rendszer, követelmény, tervezés, teszetlési terv), kódszemlézés, tesztelés (első alkalommal), auditok, CMM felmérés... <br /> * nemmegfelelőség költsége = belső hibák költsége + külső hibák költsége (mennyibe kerül “visszatérni” és javítani)<br /> ** Belső hibák költsége<br /> **: a rendszer átadása előtt megtalált hibákkal kapcsolatos költségek:<br /> **: újraírás (követelmények, tervek, modellek, kód, dokumentáció), hibajavítás miatti újratesztelés, folyamatokban jelentkező veszteségek (tesztelés miatti kiesés, átadandók változtatása, időbeli csúszások, költsége-túllépések…)<br /> ** Külső hibák költsége <br /> **: a rendszer átadása után megtalált hibákkal kapcsolatos költségek<br /> **: garancia, „apró” módosítások, sikertelen projektek, be nem tervezett verziók...<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 17., 17:11 (UTC)<br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175483 2014-01-17T18:42:30Z

<p>Halacs: /* 1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra: */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * ISO 9126 (Boehm, McCall): termék alapú; Product: metric, quality attribute, definition<br /> * ISO 9001:2000: folyamat alapú<br /> * CMM (a.k.a. CMMI): folyamat alapú<br /> * SPICE: folyamat alapú<br /> * ISO 15504:<br /> * TSP: folyamat alapú<br /> * PSP: folyamat alapú<br /> * GQM: Metric+Quality attribute: project management, technical process, product<br /> [[Fájl:szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png]]<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> A minőség nincs &quot;ingyen&quot; (megfelelőség költsége), de olcsóbb, mint a lehetséges alternatíva (nem megfelelőség költsége).<br /> <br /> '''CoQ = megfelelőség költsége + nemmegfelelőség költsége'''<br /> * megfelelőség költsége = megelőzés költsége + értékelés költsége (mennyit fektetünk abba, hogy a fejlesztésben ne kelljen javítások miatt “visszatérni”)<br /> ** Megelőzés:<br /> **: hibák megelőzésével kapcsolatos költségek:<br /> **: tervezés, dokumentálás, képzés, eszközök, eljárások és szabványok, minőségjavítási projektek, adatok gyűjtése ée elemzése, hibák okának elemzése, minőségi jelentések...<br /> ** Értékelés<br /> **: hibakereséssel kapcsolatos költségek:<br /> **: szemlék (rendszer, követelmény, tervezés, teszetlési terv), kódszemlézés, tesztelés (első alkalommal), auditok, CMM felmérés... <br /> * nemmegfelelőség költsége = belső hibák költsége + külső hibák költsége (mennyibe kerül “visszatérni” és javítani)<br /> ** Belső hibák költsége<br /> **: a rendszer átadása előtt megtalált hibákkal kapcsolatos költségek:<br /> **: újraírás (követelmények, tervek, modellek, kód, dokumentáció), hibajavítás miatti újratesztelés, folyamatokban jelentkező veszteségek (tesztelés miatti kiesés, átadandók változtatása, időbeli csúszások, költsége-túllépések…)<br /> ** Külső hibák költsége <br /> **: a rendszer átadása után megtalált hibákkal kapcsolatos költségek<br /> **: garancia, „apró” módosítások, sikertelen projektek, be nem tervezett verziók...<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 17., 17:11 (UTC)<br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175482 2014-01-17T17:11:40Z

<p>Halacs: /* 7. Mi a minőségköltsége és miből ered? */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * ISO 9126 (Boehm, McCall): termék alapú; Product: metric, quality attribute, definition<br /> * ISO 9001:2000: folyamat alapú<br /> * CMM (a.k.a. CMMI): folyamat alapú<br /> * SPICE: folyamat alapú<br /> * ISO 15504:<br /> * TSP:<br /> * PSP:<br /> * GQM: Metric+Quality attribute: project management, technical process, product<br /> [[Fájl:szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png]]<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> A minőség nincs &quot;ingyen&quot; (megfelelőség költsége), de olcsóbb, mint a lehetséges alternatíva (nem megfelelőség költsége).<br /> <br /> '''CoQ = megfelelőség költsége + nemmegfelelőség költsége'''<br /> * megfelelőség költsége = megelőzés költsége + értékelés költsége (mennyit fektetünk abba, hogy a fejlesztésben ne kelljen javítások miatt “visszatérni”)<br /> ** Megelőzés:<br /> **: hibák megelőzésével kapcsolatos költségek:<br /> **: tervezés, dokumentálás, képzés, eszközök, eljárások és szabványok, minőségjavítási projektek, adatok gyűjtése ée elemzése, hibák okának elemzése, minőségi jelentések...<br /> ** Értékelés<br /> **: hibakereséssel kapcsolatos költségek:<br /> **: szemlék (rendszer, követelmény, tervezés, teszetlési terv), kódszemlézés, tesztelés (első alkalommal), auditok, CMM felmérés... <br /> * nemmegfelelőség költsége = belső hibák költsége + külső hibák költsége (mennyibe kerül “visszatérni” és javítani)<br /> ** Belső hibák költsége<br /> **: a rendszer átadása előtt megtalált hibákkal kapcsolatos költségek:<br /> **: újraírás (követelmények, tervek, modellek, kód, dokumentáció), hibajavítás miatti újratesztelés, folyamatokban jelentkező veszteségek (tesztelés miatti kiesés, átadandók változtatása, időbeli csúszások, költsége-túllépések…)<br /> ** Külső hibák költsége <br /> **: a rendszer átadása után megtalált hibákkal kapcsolatos költségek<br /> **: garancia, „apró” módosítások, sikertelen projektek, be nem tervezett verziók...<br /> <br /> --[[Szerkesztő:Halacs|Halacs]] ([[Szerkesztővita:Halacs|vita]]) 2014. január 17., 17:11 (UTC)<br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175480 2014-01-17T17:03:22Z

<p>Halacs: /* 1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra: */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * ISO 9126 (Boehm, McCall): termék alapú; Product: metric, quality attribute, definition<br /> * ISO 9001:2000: folyamat alapú<br /> * CMM (a.k.a. CMMI): folyamat alapú<br /> * SPICE: folyamat alapú<br /> * ISO 15504:<br /> * TSP:<br /> * PSP:<br /> * GQM: Metric+Quality attribute: project management, technical process, product<br /> [[Fájl:szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png]]<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> <br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175479 2014-01-17T16:47:55Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175478 2014-01-17T16:42:35Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> Amíg a CMMI és a PSP a szervezet és az egyén képességeit fejleszti, addig a TSP termékeket állít elő.<br /> <br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175477 2014-01-17T16:39:02Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> <br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175476 2014-01-17T16:38:33Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP (Personal Software Process - egyéni fejlesztési folyamat):'''<br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP (Team Software Process):'''<br /> Ahhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges a saját munkamódszerük és a csapat munkamódszerének összekapcsolása, valamint irányítást és támogatást kapniuk a fegyelmezett munkavégzésben.<br /> <br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> A TSP célja:<br /> * Önálló, saját magukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat.<br /> * Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteni<br /> * Gyorsítani a szoftverfejlesztési folyamat javulását, a CMMI 5 szintre jellemző magatartást természetessé téve<br /> * Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban<br /> * Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175475 2014-01-17T16:18:20Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad). A PSP és TSP a CMMI-ban ismertetett folyamatcsoportokat (Key Process Area) az egyénekre és a csoportokra alkalmazza''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP: Personal Software Process - egyéni fejlesztési folyamat'''<br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> A PSP Célja<br /> * hogy segítségével a szoftverfejlesztők magas minőségű szoftvertermékeket készítsenek a tervezett (és egyeztetett) idő és öltséghatárokon belül<br /> * a termelékenység növelése.<br /> * (A fordítási és tesztelési hibák száma tipikusan 5-10-szer lesz kevesebb)<br /> <br /> '''TSP: Team Software Process'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175474 2014-01-17T16:11:12Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> ''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad).''<br /> <br /> Már a legalacsonyabb szinten is kell mérni. A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan, az nem ad konkrét mérési eljárást, sem metrikákat. Így viszont több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP: Personal Software Process - egyéni fejlesztési folyamat'''<br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> '''TSP: Team Software Process'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175473 2014-01-17T16:09:52Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> '''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg amik viszont feltételeznek egy jó minőségű keretet a fejlesztéshez (amit pedig már a CMMI ad).'''<br /> <br /> A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan. Nem ad konkrét mérési eljárást, sem metrikákat. Már legalacsonyabb szinten is kell mérni. Több kritika érte a CMM-t (ma CMMI), hogy csak a szervezettel foglalkozik, és az egyének saját folyamataira nem ad előírásokat.<br /> <br /> '''CMMI:'''<br /> * a szervezet képességeit fejleszti<br /> * a menedzsmentre fókuszál<br /> * keretet ad a jó minőségű fejlesztéshez<br /> * (feltételezi, hogy a fejlesztők hatékony módszereket használnak)<br /> <br /> '''PSP: Personal Software Process - egyéni fejlesztési folyamat'''<br /> * a csapatok teljesítményét növeli<br /> * a csapatra és a termékre fókuszál<br /> * csapattagok PSP szerint dolgoznak<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> * A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> <br /> '''TSP: Team Software Process'''<br /> * Az egyéni képességeket fejleszti<br /> * Az egyénre fókuszál<br /> * (feltételez egy jó minőségű keretet a fejlesztéshez - CMMI)<br /> * A PSP sikere után került kidolgozásra<br /> * A szervezet és az egyén közötti szintre a csoportra tartalmaz előírásokat<br /> * Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> * A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=F%C3%A1jl:Szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png&diff=175472 2014-01-17T16:03:13Z

<p>Halacs: </p> <hr /> <div></div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175471 2014-01-17T16:02:55Z

<p>Halacs: /* 1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra: */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * IsO 9126 (Boehm, McCall): Product: metric, quality attribute, definition<br /> * ISO 9001:2000<br /> * CMM:<br /> * SPICE:<br /> * CMMI:<br /> * ISO 15504:<br /> * TSP:<br /> * PSP:<br /> * GQM: Metric+Quality attribute: project management, technical process, product<br /> [[Fájl:szoftvermininoseg_vizsga_2013_szoftverminoseg-osszetevoi.png]]<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> <br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175457 2014-01-17T14:21:51Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> '''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg.'''<br /> <br /> * A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan. Nem ad konkrét mérési eljárást, sem metrikákat. Már legalacsonyabb szinten is kell mérni.<br /> * A mérés egy alapfolyamat, amely segít a munkafolyamatokat megérteni.<br /> * '''PSP: Personal Software Process - egyéni fejlesztési folyamat'''<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> ** A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> * '''TSP: Team Software Process'''<br /> ** Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175456 2014-01-17T14:18:38Z

<p>Halacs: /* 2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert! */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> '''Funkciópont számítás'''<br /> * Kifejlesztésének célja: különböző technológiákkal történő szoftverfejlesztések hatékonyságának összehasonlítása<br /> * Albrecht céljai a funkciópont számolással:<br /> ** a szoftver méretének következetes mértéke legyen<br /> ** legyen független a fejlesztésben alkalmazott technológiától<br /> ** alkalmazása legyen egyszerű, eredménye sokatmondó a végfelhasználónak (is)<br /> * Később rájöttek, hogy a módszer jól alkalmazható a specifikáció alapján történő becsléskor<br /> * A mérés minden „divatos „ modellben fontos!<br /> * A szoftveriparnak szüksége van valamilyen módszerre, amely a szoftvertermék funkcionális méretét határozza meg<br /> Problémái:<br /> * A funkciópont számolásra vonatkozó mérési program kidolgozása és fenntartása nehezebbnek bizonyult a tervezettnél<br /> ** az adatgyűjtési ráfordítás „belefolyik” a projektekbe<br /> ** az adatok elemzése nehéz, kevés a jó eredmény<br /> ** a mérési programokat folyamatosan átszervezik, csökkentik a költségeiket, egyre kevesebb időben, külsősökkel próbálják megoldani<br /> * A számolási szabályok egyre bonyolódnak<br /> * Egyre kevesebbet mond a számolás eredménye<br /> * Kritikák az akadémiai szférából<br /> * Sokfajta funkciópont számolási modell-változat<br /> * A számolások eredményei túlságosan felduzzadnak, irrelevánssá válnak<br /> <br /> '''Az IFPUG funkciópont számítási módszer'''<br /> * :) legtöbbet használták, sok a tapasztalat, esettanulmány <br /> * :) nagy nemzetközi szervezeti háttér (képzés, konzultáció, certificate…)<br /> * :) adatfeldolgozó rendszerekben jól használható<br /> * :( valós idejű rendszereknél nem használható<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> * :( a módszer struktúrája és a benne használt súlyozások (fontossági sorrendek) kérdéses<br /> <br /> '''Az MKII funkciópont számítási módszer'''<br /> * :) Menedzsment rendszerekre találták ki, és sokat is használták, jól lehet becslésben alkalmazni<br /> * :) Az IFPUG továbbfejlesztése, több adatot tartalmazó rendszerre<br /> * :) A struktúrált elemzési módszerekkel konzisztens<br /> * :) Az életciklus korai fázisában alkalmazható<br /> * :) Nagy támogatottság, képzés, certificate…( de kevesebb az IFPUG-nál)<br /> * :( használták már valós idejű rendszereknél, de ilyenkor át kell értelmezni<br /> * :( csak alkalmazás - típusú szoftverekre használható<br /> <br /> '''A COSMIC funkciópont számítási módszer'''<br /> * A szoftver funkcionalitásának egyszerű modelljén alapszik<br /> * :) Egyszerű és egyértelmű<br /> * :) Minden típusú szoftverre alkalmazható (MIS és valós idejű)<br /> * :) Többrétegű architektúrák bármely komponensének esetében is alkalmazható<br /> * :) Használták már: az IBM-nél, OO fejlesztési projektek becslésében, távközlésben, repülőgép-iparban...<br /> * :( Kevesebb a tapasztalat, kevesebb esettanulmány<br /> * :( Kevésbé részletes számolási útmutatók<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> <br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175451 2014-01-17T13:40:04Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> '''A CMMI mér, de nem tartalmaz előírásokat a mérések megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg.'''<br /> <br /> * A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan. Nem ad konkrét mérési eljárást, sem metrikákat. Már legalacsonyabb szinten is kell mérni.<br /> * A mérés egy alapfolyamat, amely segít a munkafolyamatokat megérteni.<br /> * '''PSP:''' egyéni fejlesztési folyamat<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> ** A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> * '''TSP:''' (TODO: minek a rövidítése a TSP?)<br /> ** Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175450 2014-01-17T13:39:39Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> '''A CMMI mér, de nem tartalmaz előírásokat a mérésekre megvalósítására vonatkozóan, ezeket a TSP és a PSP teszi meg.'''<br /> <br /> * A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan. Nem ad konkrét mérési eljárást, sem metrikákat. Már legalacsonyabb szinten is kell mérni.<br /> * A mérés egy alapfolyamat, amely segít a munkafolyamatokat megérteni.<br /> * '''PSP:''' egyéni fejlesztési folyamat<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> ** A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> * '''TSP:''' (TODO: minek a rövidítése a TSP?)<br /> ** Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175449 2014-01-17T13:38:47Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> '''A CMMI nem tartalmaz előírásokat a mérésekre vonatkozóan, ezt a TSP és a PSP teszi meg.'''<br /> <br /> * A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan. Nem ad konkrét mérési eljárást, sem metrikákat. Már legalacsonyabb szinten is kell mérni.<br /> * A mérés egy alapfolyamat, amely segít a munkafolyamatokat megérteni.<br /> * '''PSP:''' egyéni fejlesztési folyamat<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> ** A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> * '''TSP:''' (TODO: minek a rövidítése a TSP?)<br /> ** Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175448 2014-01-17T13:38:18Z

<p>Halacs: /* 3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> A CMMI nem tartalmaz előírásokat a mérésekre vonatkozóan, ezt a TSP teszi meg. A TSP és a PSP is mérési előírásokat tartalmaz.<br /> <br /> * A mérés jelen van a CMM-ben, de a CMM nem mérési módszertan. Nem ad konkrét mérési eljárást, sem metrikákat. Már legalacsonyabb szinten is kell mérni.<br /> * A mérés egy alapfolyamat, amely segít a munkafolyamatokat megérteni.<br /> * '''PSP:''' egyéni fejlesztési folyamat<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> ** A PSP konkrét, mérendő attribútumokat azonosít, de ezek köre igen szűk<br /> * '''TSP:''' (TODO: minek a rövidítése a TSP?)<br /> ** Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére<br /> ** A PSP pontosabb, a TSP általánosabb mérési elveket kínál<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175445 2014-01-17T13:22:59Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> ** A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejlesztő szervezete<br /> ** Változó szerepek a szervezeten belül<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175443 2014-01-17T12:09:52Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> <br /> * '''Experience Factory Organization (EF)'''<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175441 2014-01-17T12:07:24Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> * A GQM változatos módokon használható, a szoftvergyártás minden elemére<br /> * Alkalmazható a szoftverprojektre, a szoftvert előállító folyamatra és a termékre is, úgy, hogy<br /> ** A definiált metrikák a szervezethez és a szervezet céljaihoz igazodnak<br /> ** A mért adatok konstruktívak, és a szervezet tanulhat az elemzésükből.<br /> ** A metrikák és a metrikák értelmezése a különböző érdekelt felek / csoportok nézőpontját tükrözik (pl. fejlesztőkét, felhasználókét,<br /> rendszergazdákét stb.)<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására, majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> * '''Experience Factory Organization (EF)'''<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175438 2014-01-17T12:01:16Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> Eszközei:<br /> * '''Goal/Question/Metric paradigm (GQM)'''<br /> ** Gyakorlati módszer<br /> ** Eredetileg a NASA/GSFC környezetben végrehajtott projektek hibáinak felmérésére fejlesztették (Basili), azután általánosították<br /> ** 3 lépcsős mérési modellt határoz meg:<br /> **# '''Fogalmi szint (conceptual)(cél):''' Egy célt egy objektumra vonatkozóan, határozunk meg, különböző okok miatt, különböző minőségi modelleket figyelembe véve, különböző nézőpontok alapján, az objektum sajátos környezetét figyelembe véve<br /> **# '''Üzemeltetési szint (operational) (kérdés):''' Kérdéseket használunk a tanulmányozott objektumra vonatkozó modellek meghatározására,<br /> majd az objektumra koncentrálunk, hogy jellemzői segítségével egy bizonyos cél elérését vagy felmérését megvalósíthassuk<br /> **# '''Mennyiségi szint (quantitative) (metrika):''' Minden kérdéshez egy sor mérőszámot rendelünk (a korábban meghatározott modellek alapján), abból a célból, hogy a kérdésre mérhető választ tudjunk adni<br /> * '''Experience Factory Organization (EF)'''<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175437 2014-01-17T11:54:49Z

<p>Halacs: /* 1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> '''QIP'''<br /> * Minőségjavítási paradigma<br /> * Folyamatos javításra koncentrál<br /> * Az egyes projektek tapasztalatát elemzi, „csomagolja” további projektekben való felhasználhatóság szempontjából<br /> <br /> Alapfázisai:<br /> * A szoftverfolyamat megértése<br /> * Az alkalmazott technológiák (munkamódszerek) hatékonyságának<br /> figyelése, mérésekkel. Annak meghatározása, hogy mely<br /> technológiák megfelelőek az adott környezetben.<br /> * A tapasztalatok „csomagolása”. Szabványok, képzés, fejlődési<br /> stratégia kialakítása.<br /> <br /> Lépései:<br /> # A jelenlegi projekt és környezetének jellemzése a létező modellek és metrikák vonatkozásában<br /> # Mérhető célok meghatározása a sikeres projekt-teljesítményre és javításra vonatkozóan<br /> # A projekt sajátosságainak megfelelő mérési módszerek és eszközök kiválasztása<br /> # A folyamat végrehajtása, a termék előállítása, az előírt adatok összegyűjtése és validálása (hitelesítése), az adatok elemzése úgy, hogy valós időben javítási javaslatok is készüljenek<br /> # Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémák azonosítása, leírása, javítási javaslatok<br /> # A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben<br /> <br /> <br /> * GQM<br /> <br /> * EF<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175399 2014-01-16T17:02:21Z

<p>Halacs: /* 6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben. */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> <br /> TODO: ellenőrizni az alábbiakat<br /> <br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> <br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> <br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175398 2014-01-16T17:01:54Z

<p>Halacs: /* 6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben. */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> '''CMMI-SVC-ben alkalmazott folyamatok:'''<br /> TODO: ellenőrizni az alábbiakat<br /> * SCON (3) - Service Continuity<br /> * SD (2) - Service Delivery<br /> * SSD (3) - Service System Development<br /> * SST (3) - Service System Transition<br /> * STSM (3) - Strategic Service Management<br /> * CAM (3) - Capacity and Availability Management<br /> * IRP (3) - Incident Resolution and Prevention<br /> <br /> '''CCMMI-ACQ-ben alkalmazott folyamatok'''<br /> TODO: mik tartoznak ide?<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> <br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175395 2014-01-16T14:51:10Z

<p>Halacs: /* 5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175394 2014-01-16T14:48:08Z

<p>Halacs: /* 5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''HAMIS mert minden folyamat csak legalább 3-as szintű'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''IGAZ'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175393 2014-01-16T14:43:02Z

<p>Halacs: /* 5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük '''IGAZ'''<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük '''IGAZ'''<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük '''IGAZ'''<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük '''IGAZ'''<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175392 2014-01-16T14:34:04Z

<p>Halacs: /* 6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben. */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * RD (Requirement Development) - Követelményfejlesztés<br /> * TS (Technical Solution) - Műszaki megoldás<br /> * PI (Product Integration) - termék integráció<br /> * VAL (Validation) - Validáció<br /> * VER (Verification) - Verifikáció<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management <br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáció<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> <br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175391 2014-01-16T14:31:05Z

<p>Halacs: /* 6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben. */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> '''Csak CMMI-DEV:'''<br /> * Requirement Development<br /> * Technical Solution<br /> * Product Integration<br /> * Verification, Validation<br /> <br /> '''Mind a 3 konstellációban:'''<br /> * Configuration Management<br /> * Organization Process Definition<br /> * Organizational Process Performance<br /> * Quantitative Project Management<br /> * Organization Training<br /> <br /> '''Fejlesztésben (CMMI V1.2-DEV) alkalmazott folyamatok:'''<br /> * PI – termék integráció<br /> * RD - Követelményfejlesztés<br /> * SAM – Beszállítói megállapodás menedzsment<br /> * TS – Műszaki megoldás<br /> * VAL - Validáció<br /> * VER – Verifikáci<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> <br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.04.&diff=175384 2014-01-16T14:23:33Z

<p>Halacs: /* 5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk? */</p> <hr /> <div>Fejből írtam, nem vagyok mindben 100%-ig biztos -- fape<br /> <br /> ===1. A szoftver minőség mely összetevői jellemző(k) az alábbiakra:===<br /> * SPICE<br /> Software Process Improvement and Capability Determination - A szoftverminőség első folyamatközpontú megközelítése<br /> * Boehm modell<br /> A szoftver egyik első termékközpontú megközelítése<br /> * Automotive SPICE<br /> A SPICE modell autóipari alkalmazásra átalakított változata. Folyamatközpontú megközelítés.<br /> * ISO 9126<br /> A termékközpontú szoftverminőség újragondolása. <br /> * IFPUG<br /> International Function Point Users Group - A Funkciópontszámítás módszerének használóinak világméretű szervezete.<br /> A funkciópontszámítás egy termékalapú metrikát határoz meg, amely segítségével programnyelvfüggetlen módon határozható meg egy adott probléma mérete funkciópontokban.<br /> * CMMI<br /> Capability Maturity Model Integration - Az amerikai Software Engineering Institue által kidolgozott folyamatközpontú modell.<br /> * PSP<br /> Personal Software Process - Eredetileg Watts Humphrey által kidolgozott, a szoftverfejlesztők személyes munkavégzésére koncentráló módszertan, amely az eredeti CMM és a későbbi CMMI 5. érettségi szintjének megfelelő munkafolyamatokat honosít meg a szoftverfejlesztői munkavégzés szintjén. Folyamatközpontú.<br /> * TSP<br /> Team Software Process - A PSP szerint dolgozó szoftverfejlesztők együttes munkavégzésének az optimális összehangolását bizosító módszertan. Folyamatközpontú.<br /> * GQM<br /> Goal Question Metric<br /> * ISO 9000:2000<br /> <br /> ===2. Mi a funkciópont számítás? Röviden ismertesse a COSMIC módszert!===<br /> <br /> ===3. Értelmezze a &quot;Mérés és elemzés (MA)&quot;, a &quot;Konfigurációmenedzsment (CM)&quot; és a &quot;Folyamat- és termék minőségbiztosítás (PPQA)&quot; folyamatokra az alábbi általános célokat:===<br /> * GP 2.6 Konfigurációk menedzsmentje.<br /> * GP 2.8 Folyamatkövetés és &amp;#8211;vezérlés.<br /> * GP 2.9 A megfelelőség tárgyilagos kiértékelése. <br /> <br /> ===4. Az előző célok közül melyeknek felelnek meg:===<br /> * GQM<br /> * ISO 9001:2000<br /> <br /> ===5. Mi a CMMI-DEV, CMMI-SVC, CMMI-ACQ. A szoftver életciklusában mikor melyiket alkalmazhatjuk?===<br /> Mind a három egy-egy CMMI konstelláció rövidítése. A konstellációk tulajdonképpen valamilyen szakterülethez kapcsolódó sajátos folyamatokat írnak le. Ezek a konstellációk (azaz szakterületek) a következők:<br /> * CMMI-DEV - Fejlesztés<br /> * CMMI-SVC - Szolgáltatás<br /> * CMMI-ACQ - Beszerzés<br /> <br /> ===6. Írjon 5 olyan folyamatot, ami megtalálható mind 3 konstellációban (CMMI-DEV, CMMI-SVC, CMMI-ACQ). Valamint 3 olyat folyamatot amely csak a CMMI-DEV-ben.===<br /> Csak CMMI-DEV:<br /> Requirement Development, Technical Solution, Product Integration, Verification, Validation<br /> Mind a 3 konstellációban:<br /> Configuration Management, Organization Process Definition, Organizational Process Performance, Quantitative Project Management, Organization Training<br /> <br /> ===7. Mi a minőségköltsége és miből ered?===<br /> <br /> <br /> -- [[FaPe|FaPe]] - 2011.01.06.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175383 2014-01-16T14:10:59Z

<p>Halacs: /* 5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> ''leírják, hogy mit kötelező implementálni ahhoz, hogy kielégítsük az adott folyamatcsoportot''<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175305 2014-01-15T10:31:40Z

<p>Halacs: /* 2. Garvin szoftverminőség-definíciói - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szoftvermin%C5%91s%C3%A9g_-_Vizsga_2011.01.17.&diff=175304 2014-01-15T10:31:13Z

<p>Halacs: /* 2. Garvin szoftverminőség-definíciói - 5p */</p> <hr /> <div>Én is fejből írtam, és én sem vagyok mindben 100%-ig biztos :]<br /> Főleg az igaz-hamis feladatoknál lehetnek pontatlanságok.<br /> <br /> ===1. QIP-t és 2 jellemző módszere (GQM, EF) - 5p===<br /> <br /> ===2. Garvin szoftverminőség-definíciói - 5p===<br /> '''Transzcendens definíció:'''<br /> – A minőség a veleszületett kiválóságot jelenti.<br /> Eszerint a minőség abszolút, egyetemes - annak<br /> ellenére, hogy nem lehet pontosan meghatározni.<br /> A minőséget csakis tapasztalat alapján lehet<br /> felismerni.<br /> <br /> '''Felhasználói alapú definíció:'''<br /> – A minőség a felhasználásra való alkalmasság. Ez<br /> a definíció abból indul ki, hogy, mivel a<br /> felhasználóknak egyedi igényeik vannak, az a<br /> legjobb minőségű termék, amelyik ezeket az<br /> igényeket a legmagasabb fokon kielégíti.<br /> <br /> '''Érték alapú definíció:'''<br /> – A minőséget a költség függvényében határozza<br /> meg. Eszerint a jó minőségű termék alacsony<br /> áron alkalmas a kitűzött feladat elvégzésére,<br /> illetve elfogadható nagyságú költségek mellett<br /> felel meg a specifikációjának.<br /> <br /> '''Termék alapú definíció:'''<br /> – A minőség precíz és mérhető változó. A<br /> minőségi különbségek a termékek egyes<br /> összetevőinek vagy jellemzőinek a<br /> különbségeiből fakadnak. A minőség tehát nem<br /> megítélés kérdése, hanem a termékben rejlő -<br /> objektív - jellemző.<br /> <br /> '''Folyamat alapú definíció:'''<br /> – A minőség a specifikációnak való megfelelőséget<br /> jelenti.<br /> <br /> ===3. Mi a TSP? Hogyan kapcsolódik a PSP-hez és CMMI-hez? - 3p===<br /> <br /> ===4. ISO 9001:2000 kötelező eljárási utasításaira vonatkozó dokumentumok - 5p===<br /> <br /> ===5. Igaz-hamis, igazt karikázni, hamist X-elni. Jó válasz +1, rossz válasz -1, nincs válasz 0. - 12p===<br /> <br /> # A CMMI-ben<br /> #*a. az általános célok (GG) azt adják meg, hogy ... (nem emlékszem)<br /> #*b. 2. érettségi szintű folyamat jellemzője többek között ...<br /> #*c. 2. érettségi szinten levő folyamatnál ...<br /> #*d. 4. érettségi szinten levő folyamatnál kötelező a mérési mutatókat dokumentálni<br /> # A CMMI-ben<br /> #*a. 2-es érettségi szinten levő folyamatoknak legalább 2-es képességi szinten kell lenniük<br /> #*b. 3-as érettségi szinten levő folyamatoknak legalább 3-as képességi szinten kell lenniük<br /> #*c. 4-es érettségi szinten levő folyamatoknak legalább 4-es képességi szinten kell lenniük<br /> #*d. 5-ös érettségi szinten levő folyamatoknak legalább 5-ös képességi szinten kell lenniük<br /> # A CMMI<br /> #*a. használható szoftver- és rendszerfejlesztésre is<br /> #*b. TQM szemléletű<br /> #*c. csak PSP-vel együtt használható<br /> #*d. folytonos modellje a SPICE-ra alapul<br /> <br /> -- [[BalazsPapp]] - 2011.01.17.<br /> <br /> [[Category:InfoMsc]]</div>

Halacs https://vik.wiki/index.php?title=Szerkeszt%C5%91:Halacs&diff=172836 2013-11-06T08:01:38Z

<p>Halacs: Új oldal, tartalma: „https://profile.sch.bme.hu/profile/show/uid/halacs”</p> <hr /> <div>https://profile.sch.bme.hu/profile/show/uid/halacs</div>

Halacs https://vik.wiki/index.php?title=%E2%80%98Big_Data%E2%80%99_elemz%C3%A9si_eszk%C3%B6z%C3%B6k_ny%C3%ADlt_forr%C3%A1sk%C3%B3d%C3%BA_platformokon&diff=172835 2013-11-06T07:57:00Z

<p>Halacs: /* 2013/2014 */</p> <hr /> <div>{{Szabvál<br /> |nev=‘Big Data’ elemzési eszközök&lt;br&gt;nyílt forráskódú platformokon<br /> |kredit=2<br /> |tárgykód=BMEVITMAV15<br /> |tanszék=TMIT<br /> |kiszh=nincs<br /> |nagyzh=1 db<br /> |vizsga=nincs<br /> |hf=van<br /> |jelenlét=ajánlott (nincs jegyzet)<br /> |minmunka=kis utánaolvasás<br /> |tad=https://www.vik.bme.hu/kepzes/targyak/VITMAV15/<br /> |targyhonlap=http://adatbanyaszat.tmit.bme.hu/twiki/bin/view/Targyak/BigData2013<br /> }}<br /> <br /> A tárgy célja, hogy megismertesse a hallgatókkal a big data elemzésére alkalmas módszereket és algoritmusokat, különös tekintettel a széles körben elterjedt nyílt forráskódú technológiákra. A példák és a házi feladatok a Hadoop keretrendszerhez és más hozzá kapcsolódó technológiákhoz nyújtanak gyakorlati ismereteket. A hallgatók képesek lesznek nagy adatok elemzésére alkalmas rendszerek megtervezésére, létrehozására és elemzési feladatok megvalósítására.<br /> <br /> __TOC__<br /> <br /> == Követelmények ==<br /> <br /> *'''Jelenlét:''' Ajánlott mert nincs jegyzet<br /> *'''NagyZH:''' TODO<br /> *'''Házi:''' TODO<br /> <br /> &quot;A tárgy jegyének megszerzéséhez a ZH legalább elégséges teljesítése szükséges, valamint egy házi feladat elkészítése és megvédése. Az érdemjegyet a ZH illetve a házifeladat érdemjegyének átlagával számítjuk ki, a 0.5-re végződő eredményeket felfele kerekítjük. ZH a 8. vagy a 9. héten, pótZH és házifeladat bemutatása a 14. héten lesz.&quot;<br /> <br /> ==Számonkérések==<br /> <br /> ===Házifeladat===<br /> Részletesen: http://adatbanyaszat.tmit.bme.hu/twiki/bin/view/Targyak/BigData2013Hazi<br /> <br /> ====Feladatok és eszközök kiválasztása====<br /> Az alábbi feladatok közül a használt eszközök fényében kell néhány darabot kiválasztani. A használható eszközök és a megoldandó feladatok száma:<br /> * Java MapReduce programozás: 1 feladat<br /> * Hadoop Streaming programozás más programnyelven (Python, R, stb.): 2 feladat<br /> * Hive és Pig: 3 feladat <br /> Ha tehát valaki Hive-ban és Pig-ben akar dolgozni, akkor az alábbi feladatok közül 3-at is meg kell oldania és mindkét eszközt használnia kell, tehát mondjuk 2 feladat Hive-ban, 1 feladat Pig-ben. Ezzel szemben ha valaki Java programozással akar MapReduce elemzést csinálni, akkor az alábbiak közül elegendő egyetlen szabadon választott feladat megoldása. Hadoop Streaming esetén 2 feladat megoldása szükséges. <br /> <br /> ====Választható feladatok====<br /> * '''HTML lapletöltések hisztogramja''': az adatokból egy olyan grafikont kell kirajzolni, mely bemutatja, hogy hány olyan kliens (host) volt, aki 0 darab html oldalt töltött le, hány olyan aki 1-et, 2-t, stb. Az elemzés kimenete tehát egy két oszlopot tartalmazó tábla (html letöltésszám, hostok száma), illetve egy grafikon, amely bármely megjelenítő programmal (pl. Excel) előállítható. <br /> * '''Utolsó 2 letöltött HTML oldal''': minden egyes kliens (host) esetén ki kell gyűjteni az (időben) utolsó 2 letöltött HTML oldalt. Az eredmény tehát egy három oszlopot tartalmazó tábla (host, utolsó html oldal, utolsó előtti html oldal). Ha egy kliens (host) nem töltött le két html oldalt, akkor a megfelelő mezők üresen maradjanak.<br /> * '''Napi egyedi látogatók (hosztok) száma''': számítsuk ki minden napra, hogy hány egyedi látogató (host) volt aznap az oldalon, majd ezt ábrázoljuk grafikonon. <br /> * '''Visszatérő látogatók (hosztok) listája''': Visszatérő látogatónak tekintjük azt a hostot, ami két (vagy több) különböző napon is meglátogatta az oldalt és a legkorábbi és legkésőbbi lapletöltése között legalább 6 óra telt el. Ezzel kiszűrjük azokat a látogatókat, akik éjfél előtt és éjfél után közvetlenül látogatják meg az oldalt. A megoldás ezen látogatók listája és darabszáma.<br /> <br /> ===Zárthelyi===<br /> * Előrevetíti: konkrét elemzési feladat (pl átlag) megvalósítása mapredben. Joinolni nem kell tudni. Akármilyen nyilazós sémás dologgal is megoldható nem kell java kódot írni. Pl:<br /> <br /> Kell: minden nap hány külöböző sessionid volt egy nap?<br /> SELECT date, COUNT(DISTINCT sessionid) FROM table GROUP BY date<br /> M:(sorid,sor)-&gt;(date+session, 1)<br /> R:(date+session,list(1))-&gt;(date+sessionid,1)<br /> M:(date+sessionid,1)-&gt;(date,1)<br /> R:(date, list(1))-&gt;(date,sum)<br /> <br /> <br /> * TODO<br /> <br /> == Segédanyagok ==<br /> <br /> A kurzusok anyagai a TMIT honlapján:<br /> * [http://adatbanyaszat.tmit.bme.hu/twiki/bin/view/Targyak/BigData2013 2013/2014 ősz]<br /> <br /> == Tapasztalatok ==<br /> <br /> === 2013/2014 ===<br /> A tárgy először 2013/2014 őszén került meghirdetésre.<br /> <br /> Én MapReduce-os házit csináltam, az egyáltalán nem volt gáz. A kiadott VM-en minden megvan ami kell, csak legyen min futtatni magát a VM-et. Ha elég jól megy a Java és megvan, hogy elvben mit csinál a Map és mit a Reduce, akkor hamar meg lehet csinálni.<br /> <br /> [[Category:Gazdhuman]]</div>

Halacs https://vik.wiki/index.php?title=%E2%80%98Big_Data%E2%80%99_elemz%C3%A9si_eszk%C3%B6z%C3%B6k_ny%C3%ADlt_forr%C3%A1sk%C3%B3d%C3%BA_platformokon&diff=172834 2013-11-06T07:56:44Z

<p>Halacs: /* 2013/2014 */</p> <hr /> <div>{{Szabvál<br /> |nev=‘Big Data’ elemzési eszközök&lt;br&gt;nyílt forráskódú platformokon<br /> |kredit=2<br /> |tárgykód=BMEVITMAV15<br /> |tanszék=TMIT<br /> |kiszh=nincs<br /> |nagyzh=1 db<br /> |vizsga=nincs<br /> |hf=van<br /> |jelenlét=ajánlott (nincs jegyzet)<br /> |minmunka=kis utánaolvasás<br /> |tad=https://www.vik.bme.hu/kepzes/targyak/VITMAV15/<br /> |targyhonlap=http://adatbanyaszat.tmit.bme.hu/twiki/bin/view/Targyak/BigData2013<br /> }}<br /> <br /> A tárgy célja, hogy megismertesse a hallgatókkal a big data elemzésére alkalmas módszereket és algoritmusokat, különös tekintettel a széles körben elterjedt nyílt forráskódú technológiákra. A példák és a házi feladatok a Hadoop keretrendszerhez és más hozzá kapcsolódó technológiákhoz nyújtanak gyakorlati ismereteket. A hallgatók képesek lesznek nagy adatok elemzésére alkalmas rendszerek megtervezésére, létrehozására és elemzési feladatok megvalósítására.<br /> <br /> __TOC__<br /> <br /> == Követelmények ==<br /> <br /> *'''Jelenlét:''' Ajánlott mert nincs jegyzet<br /> *'''NagyZH:''' TODO<br /> *'''Házi:''' TODO<br /> <br /> &quot;A tárgy jegyének megszerzéséhez a ZH legalább elégséges teljesítése szükséges, valamint egy házi feladat elkészítése és megvédése. Az érdemjegyet a ZH illetve a házifeladat érdemjegyének átlagával számítjuk ki, a 0.5-re végződő eredményeket felfele kerekítjük. ZH a 8. vagy a 9. héten, pótZH és házifeladat bemutatása a 14. héten lesz.&quot;<br /> <br /> ==Számonkérések==<br /> <br /> ===Házifeladat===<br /> Részletesen: http://adatbanyaszat.tmit.bme.hu/twiki/bin/view/Targyak/BigData2013Hazi<br /> <br /> ====Feladatok és eszközök kiválasztása====<br /> Az alábbi feladatok közül a használt eszközök fényében kell néhány darabot kiválasztani. A használható eszközök és a megoldandó feladatok száma:<br /> * Java MapReduce programozás: 1 feladat<br /> * Hadoop Streaming programozás más programnyelven (Python, R, stb.): 2 feladat<br /> * Hive és Pig: 3 feladat <br /> Ha tehát valaki Hive-ban és Pig-ben akar dolgozni, akkor az alábbi feladatok közül 3-at is meg kell oldania és mindkét eszközt használnia kell, tehát mondjuk 2 feladat Hive-ban, 1 feladat Pig-ben. Ezzel szemben ha valaki Java programozással akar MapReduce elemzést csinálni, akkor az alábbiak közül elegendő egyetlen szabadon választott feladat megoldása. Hadoop Streaming esetén 2 feladat megoldása szükséges. <br /> <br /> ====Választható feladatok====<br /> * '''HTML lapletöltések hisztogramja''': az adatokból egy olyan grafikont kell kirajzolni, mely bemutatja, hogy hány olyan kliens (host) volt, aki 0 darab html oldalt töltött le, hány olyan aki 1-et, 2-t, stb. Az elemzés kimenete tehát egy két oszlopot tartalmazó tábla (html letöltésszám, hostok száma), illetve egy grafikon, amely bármely megjelenítő programmal (pl. Excel) előállítható. <br /> * '''Utolsó 2 letöltött HTML oldal''': minden egyes kliens (host) esetén ki kell gyűjteni az (időben) utolsó 2 letöltött HTML oldalt. Az eredmény tehát egy három oszlopot tartalmazó tábla (host, utolsó html oldal, utolsó előtti html oldal). Ha egy kliens (host) nem töltött le két html oldalt, akkor a megfelelő mezők üresen maradjanak.<br /> * '''Napi egyedi látogatók (hosztok) száma''': számítsuk ki minden napra, hogy hány egyedi látogató (host) volt aznap az oldalon, majd ezt ábrázoljuk grafikonon. <br /> * '''Visszatérő látogatók (hosztok) listája''': Visszatérő látogatónak tekintjük azt a hostot, ami két (vagy több) különböző napon is meglátogatta az oldalt és a legkorábbi és legkésőbbi lapletöltése között legalább 6 óra telt el. Ezzel kiszűrjük azokat a látogatókat, akik éjfél előtt és éjfél után közvetlenül látogatják meg az oldalt. A megoldás ezen látogatók listája és darabszáma.<br /> <br /> ===Zárthelyi===<br /> * Előrevetíti: konkrét elemzési feladat (pl átlag) megvalósítása mapredben. Joinolni nem kell tudni. Akármilyen nyilazós sémás dologgal is megoldható nem kell java kódot írni. Pl:<br /> <br /> Kell: minden nap hány külöböző sessionid volt egy nap?<br /> SELECT date, COUNT(DISTINCT sessionid) FROM table GROUP BY date<br /> M:(sorid,sor)-&gt;(date+session, 1)<br /> R:(date+session,list(1))-&gt;(date+sessionid,1)<br /> M:(date+sessionid,1)-&gt;(date,1)<br /> R:(date, list(1))-&gt;(date,sum)<br /> <br /> <br /> * TODO<br /> <br /> == Segédanyagok ==<br /> <br /> A kurzusok anyagai a TMIT honlapján:<br /> * [http://adatbanyaszat.tmit.bme.hu/twiki/bin/view/Targyak/BigData2013 2013/2014 ősz]<br /> <br /> == Tapasztalatok ==<br /> <br /> === 2013/2014 ===<br /> A tárgy először 2013/2014 őszén került meghirdetésre.<br /> <br /> Én MapReduce-os házit csináltam, az egyáltalán nem volt gáz. A kiadott VM-en minden megvan ami kell, csak legyen min futtatni magát a VM-et. Ha elég jól megy a Java és megvan mit csinál a Map és mit a Reduce, akkor hamar meg lehet csinálni.<br /> <br /> [[Category:Gazdhuman]]</div>

Halacs