Egy szoftver fejlesztésének az életciklusa 4 fő lépésből áll: Követelmények összegyűjtése, specifikáció Tervezés Fejlesztés, megvalósítás Tesztelés +1: Karbantartás (az első átadás/kiadás után folyamatos) Attól függően, hogy ez a négy elem hogyan kapcsolódik egymáshoz, különféle módszertanokat különböztetünk meg. A gyakorlatban ahány cég/csapat, annyiféle módszer létezik, ezért most csak legfontosabbakkal, a főbb kategóriákkal ismerkedünk meg. Vízesés A fázisok elkülönülnek egymástól, egymásra épülnek: A naiv elgondolás, hogy ez a módszer a logikus, hiszen hogyan is lehetne elkezdeni a tervezést a specifikáció nélkül, hogyan lehetne tesztelni kész szoftver nélkül stb. ...

Nyílt forráskódú szoftvernek azt nevezzük, amikor a szoftver forráskódja a fejlesztők számára szabadon elérhető, és az módosítható, akár saját programba be is építhető. Köznyelvben a nyílt forráskódú (open-source) és a szabad (free/libre) szoftver fogalma rokon értelmű. Attól, hogy a forráskód elérhető, még nem lesz a szoftver nyílt: a Windows operációs rendszer forráskódja bizonyos célokra (pl. hardverfejlesztés) bizonyos feltételek mellett (pl. több ezer fős cég, titoktartási nyilatkozat) megtekinthető. Szabad ≠ ingyenes Az angol “free software” kifejezés félrevezető lehet, ezért szokás az “Open source” vagy a “Free/Libre” kifejezést használni. ...

Két fő fogalmat kell tisztázni, mielőtt a tesztelés módszereibe belekezdenénk: Verifikáció: Amit elkészítünk, az helyesen működik-e? Validáció: A jó szoftvert készítjük-e, megoldja-e az ügyfél/felhasználó problémáját? A validációt akár már a tervezési fázisban, még az első programkódsor leírása előtt el tudjuk kezdeni. Verifikálni viszont értelemszerűen csak elkészült programot lehet. A tesztelési módszereket sokféleképp lehet csoportosítani, és ideálisan mindegyiket használjuk a megfelelő szinteken: Automatikus vs. Kézi Automatikus: a teszteket számítógép értékeli ki, és egyértelmű visszajelzést ad a sikerről. Előny: Könnyen megismételhető Akár nagyon sok tesztesetet is végig tud nézni Tesztelés közben (ideális esetben) nem hibázik Hátrány: Teszteseteket pontosan meg kell fogalmazni Nem minden esetben alkalmazható Kézi: a teszteket ember végzi el. Előny: Olyan hibákra is ráakadhatunk, amelyeket előre nem specifikáltunk “Szubjektív” hibákat is lehet ellenőrzni (pl. grafikus felület átláthatósága) Hátrány: Az emberi erőforrás drága Tesztelés közben nagyobb a hiba esélye, főleg repetitív feladatoknál Szisztematikus vs. ad-hoc Szisztematikus A teszteseteket előre definiáljuk, és előre megadott módszerrel értékeljük ki Lehet automatikus vagy kézi Ad-hoc A tesztelőnek szabad kezet adunk, nincsenek instrukciók Csak kézi Feketedoboz vs. fehérdoboz Feketedoboz: Nem ismerjük a szoftver belső felépítését Adott bemenetre adott kimenetet kell adni, a belső felépítést nem nézzük Fehérdoboz: A bemenetet úgy választjuk meg, hogy minden elágazás, ciklus, belső függvény stb. legyen tesztelve A kód-lefedettséget IDE-eszközökkel lehet mérni Tesztelési szintek Egységtesztelés Egyetlen osztályt, függvényt tesztelünk, a programtól izoláltan. ...

A jogi ismeretek legfontosabb szabálya, hogy ha bármi nem 100%-osan világos, akkor ügyvédet kell megkérdezni. Jogi problémák esetében sokat veszthetünk, ha “Úgy hallottam, hogy…”, “Szerintem…” típusú tanácsokra hagyatkozunk. Ebbe természetesen az alábbi összefoglaló is beletartozik, és nem tekinthető jogi tanácsadásnak. A leírás pedig csak összefoglaló, nem teljeskörű, és csak a magyar jogrendszerre érvényes. Ettől függetlenül azért célszerű tisztában lenni a legfontosabb, szoftverfejlesztés során előkerülő jogi szabályokkal: Tudjuk, hogy milyen szoftvert, asset-et használhatunk fel, és milyen feltételek mellett Tudjuk, hogy a saját termékünket milyen módokon lehet megvédeni. Itt most három fajta oltalmat fogunk megvizsgálni: ...

2024-11-30 frissítés: Hibajavítás, ill. kiegészítés az újabb .NET, NUnit verziókhoz. A tesztelés legalacsonyabb szintje az egységtesztelés (unit testing), mivel a programnak a legkisebb, önállóan is értelmes egységeit teszteli. Ez OOP programnyelvekben a függvény és az osztály, de többnyire az utóbbi. Az egységtesztelés célje, hogy meggyőződjünk arról, hogy a programunk építőkockái önállóan is helyesen működjenek – csak helyes elemekből lehet jól működő alkalmazást építeni. Egy összetettebb alkalmazás sok kisebb komponensből áll, a teszteléshez ezért rendkívül sok bemeneti kombinációt kellene kipróbálni, ami hasonló mértékű kimenetet produkál. A tesztek száma egy közepes méretű alkalmazásban is minden gond nélkül elérheti a több száz, vagy akár ezer esetet is, amit emberi erőforrással már lehetetlen kivitelezni. Emiatt az egységtesztelés szinte kivétel nélkül automatizált. ...

Az adatszerkezeteket kétféleképp is megkülönböztethetjük. Felépítés szerint (pl. tömb, fa, hash tábla), vagy pedig a rajtuk elvégezhető műveletek szerint: Adatszerkezetek (a felépítés szerinti) Absztrakt adattípusok (műveletek szerint) Itt most az utóbbiból mutatok be néhányat. Verem Angolul stack LIFO (Last-in First-out) A verem két műveletet definiál: push → beletesz egy elemet pop → kiveszi azt az elemet, amelyet legutóljára tettünk bele. Az alábbi módon tudjuk elképzelni: v = új üres Verem() // [] v.push(5) // [5] v.push(10) // [5, 10] v.push(-1) // [5, 10, -1] Kiír(v.pop()) // [5, 10] Ki: -1 Kiír(v.pop()) // [5] Ki: 10 Sor Angolul queue FIFO (First-in First-out) A sor szintén két műveletet definiál: ...

A gráfokon különféle algoritmusokat végezhetünk el, ehhez pedig először egy konkrét, objektum-orientált adatszerkezetet kell definiálnunk: A gráf külső iterfészét a Graf osztály fogja jelenteni. Az ehhez tartozó metódusokkal fogjuk a gráfot kezelni, az algoritmusokat lefuttatni - a gráf használójának nem kell tudni a belső felépítésről, a Csucs és El osztályokról. A tárolás módja éllista lesz, ahol minden élt az El osztály egy példánya fogja jelenteni. A könnyebb kezelhetőség kedvéért az élt úgy tároljuk el, hogy mindkét irányt felvesszük, vagyis ha szerepel az 1-3 él, akkor a 3-1 is szerepelni fog. ...

A gráf egy olyan adatszerkezet, amely csúcsokból/pontokból, és azokat összekötő élekből áll. Ez pl. egy gráf: A gráfokat tipikusan olyan helyzetekben alkalmazzuk, amikor különféle dolgok kapcsolatáról beszélünk. Ez lehet egy metróhálózat: Vagy diákok, akiknek legjobb barátaik vannak: Néhány hasznos kifejezés, szakszó A gráf összefüggő, ha bármely pontjából bármely pontjába el lehet jutni. Ez pl. egy nem összefüggő gráf: A gráf irányított, ha ez éleknek van egy kiinduló és egy végpontja. A fenti legjobb barát gráf irányított, míg a metróhálózat irányítatlan. ...

Nyílt forráskódú projekt esetében előfordul, hogy más kódjához mi magunk is hozzá szeretnénk nyúlni, szeretnénk bele fejleszteni, ki szeretnénk egészíteni. Érthető okokból azonban a projektek tulajdonosai nem adnak bárkinek hozzáférést a repóhoz. Emiatt szükség lesz egy saját változatra. Megtehetjük azt, hogy saját magunk leklónozzuk a projektet, majd módosítva a “remote” beállításokat egy saját, üres repóba feltöltjük. Ezt hívjuk a repó fork-olásának (a szó azt jelenti, hogy elágazás: ahogy az út egyből kettéágazik, vagy ahogy a villa egy nyeléből több kisebb “ág” nő ki). ...