Gyakorlati alapok II.
A szoftverfejlesztés
Szoftverfejlesztési modellek
Az alábbi fejezet Sallay András informatikatanár oktatási anyagára támaszkodik (www.szit.hu)
A kidolgozás azt jelenti, amit: a programterv alapján lekódoljuk a kódfeladatokat (implementálás), ezután pedig teszteljük a megírt kódsorokat. Néhány ilyen jellegű, JUnit nevű keretrendszerrel készült tesztet olvashatunk a Skálakereső teljes forráskódja (Java) című projektemben, a HangkombinacioTeszt.java című résznél.
Az ügy itt kezd bonyolulttá válni, mert a tesztelés olyan fontossá vált, hogy már régesrég önálló szakmát alkot. Sőt, amit manapság teszünk, az sokszor már nem az implementálás-tesztelés megszokott folyamata, hanem pontosan a fordítottja: először tesztelünk, majd ehhez írjuk meg a kódot. Ezt, a 2000-es évektől már igen elterjedt kódfejlesztési módszert nevezzük TDD-nek (Test-Driven Development - Tesztvezérelt fejlesztés). De ne rohanjunk ennyire előre, mert a TDD ismertetése előtt még meg kell ismernünk néhány további szoftverfejlesztési modellt is. Némelyik már idejétmúlt, de egymás után, a fejlődés folyamatában látni őket mindenképpen hasznos tanulság.
A legrégebbi fejlesztési modell, fázismodellnek is hívják. Fő jellegzetessége, hogy az egyes fázisokra nincs visszatérés, ezért az a vízesésre (vagy bármi lejtős tereptárgyra) emlékeztet:
Forrás - Source: www.szit.hu
Az egész fejlesztés voltaképpen egyetlen szekvenciális folyamat. Ez persze a gyakorlatban nem működik, mert egy adott ponthoz való kényszerű visszatérés annál költségesebb, minél nagyobbat kell visszalépnünk. Hibái és elavultsága miatt ritkán használjuk. Elsőként Winston W. Royce (1929-1995) írta le a modellt, aki köztudottan a szoftverfejlesztés egyik úttörője volt a California Institute of Technology nevű kutatóintézetnél.
Előnyei:
egyszerűen menedzselhető,
a fejlesztési lépések könnyen átláthatók, tervezhetők.
Hátrányai:
előre megköveteli az ügyféltől, hogy véglegesítse követelményeit,
megköveteli a fejlesztőtől, hogy előre válasszon ki egy tervezési stratégiát,
nagy és bonyolult rendszerek jöhetnek létre, amelyek alkalmatlanok lesznek a változtatásra.
Készítünk egy kezdeti, csak alapokban kidolgozott megvalósítást (prototípus),
ezt véleményeztetjük a felhasználóval. Ezután igényei szerint finomítunk a
prototípuson, amelyet újfent véleményeztetünk és így fog ez alkotni ciklikus
folyamatot:
Forrás - Source: www.szit.hu
Előnyei:
felhasználó-centrikus,
gyors visszacsatolás a felhasználó részéről,
a fejlesztési lépések könnyen követhetők.
Hátrányai:
nem szab gátat a felhasználó elvárásainak, mert a ciklikus folyamatot éppen az irányítja,
sok verzió fog keletkezni,
a tervezéssel kapcsolatos döntések a ciklikusság miatt elmaradnak. Ennek eredménye nehezen érthető szoftver és gyenge felépítés lesz.
Pontosan a vízesés-, és az
evolúciós modell között helyezkedik el.
Lépései:
elsőként egy vázlatos követelményrendszert állítunk össze,
osztályozzuk a szolgáltatásokat fontosságuk szerint,
a fontosakat elkezdjük megvalósítani,
alváltozatokra osztva a fejlesztést, több változatot hozunk létre,
az egyes változatokat is több lépésben hozzuk létre.
Forrás - Source: www.szit.hu
A modellt először 1986-ban Barry W. Boehm (1935) szoftvermérnök javasolta.
Jellemzői:
nem tevékenységek és visszalépések sorozata, hanem inkább fejlesztési spirál,
a fejlesztés 4, egymástól elkülönített lépcsőben, ciklikusan történik,
minden ciklus célkitűzéssel indul.
Forrás - Source: www.szit.hu
Iteratív, más néven folyamatiterációs modellnek is hívják.
Jellemzői:
a fejlesztést rendszeresen ismétlődő tevékenységnek (iterációnak) tekintjük,
ebből következően kis inkrementációs lépésekből áll,a specifikáció nem előre, hanem a szoftverrel együtt készül.
Forrás - Source: www.testingexcellence.com
A korai fejlesztések egyike, a német védelmi minisztérium (Bundesministerium
der Verteidigung) dolgozta ki biztonsági okokból. Nemcsak modell, hanem
már módszertan is, ezért a biztonságkritikus számítógépek fejlesztésénél
terjedt el. A szoftverfejlesztési sorrend nem szigorúan vett.
Forrás - Source: www.szit.hu
Ennél a pontnál kell tisztáznunk a validálás és a verifikálás fogalmait, bár nyilvánvalóan funkcionálisan jóval hamarabb is előfordultak.
A tisztaszoba (cleanroom) magas színvonalú, hitelesíthető szoftverek
fejlesztésénél használt eljárás. Először Harlan Mills (1919-1996)
számítógéptudós használta az IBM kutatórészlegeiben.
Jellemzői:
a hibák eltávolítása helyett a hangsúly azok megelőzésén van,
egy egész csapat ellenőrzi, hogy a tervezés helyes úton jár-e,
fokozatos fejlesztés jellemzi, iteratív megközelítéssel,
előre meghatározott szabványokban mérik a munkafolyamat előrehaladását,
a tesztelést, mint statisztikai eljárást hajtják végre.
Forrás - Source: slideplayer.com
A Rational Unified Process szavak rövidítése, jelentése nagyjából
ésszerűen (vagy arányosan) egyesített folyamat.
A Rational Software Corporation nevű cég fejlesztette ki, amit később
az IBM felvásárolt. Egy agilis szoftverfejlesztési megközelítés, amely
igyekszik több folyamatmodellt is ötvözni. Fontosságára jellemző, hogy
Angster Erzsébet -
Objektumorientált tervezés és programozás, JAVA című 2 kötetes munkájában
csakis erre a modellre hivatkozik:
Forrás - Source:
www.szit.hu
Jellemzői:
iteratív fejlesztés,
konkrét célkitűzések,
mire kell figyelni,
mire nem kell figyelni,
becsülhető idő - iterációk segítik a becslést,
komponensek fejlesztése,
minőségbiztosítás,
változás-kezelés.
A következő listában a RUP rendszerfejlesztési fázisait látjuk:
előkészítés
vázlatos elképzelés készítése
cél a megbecsülhető költség
szerkezet (architektúra) kialakítása
kidolgozás
használati esetek részletes kidolgozása
alaparchitektúra kidolgozása
megvalósítás
a teljes rendszer megvalósítása
rendszerterv
programozás
tesztelés
átadás
béta változat
gyakorlott felhasználók tesztelik, jelentést készítenek
hibák megoldása
hiányzó részek pótlása
Minden új fázis kezdete egy úgynevezett mérföldkő.
A modellnek más variációi, verziói is létrejöttek:
Agile Unified Process (AUP),
Basic Unified Process (BUP) - IBM, az OpenUP előfutára,
Enterprise Unified Process (EUP) - a Rational Unified Process kiterjesztése,
Essential Unified Process (EssUP),
Open Unified Process (OpenUP) - „Eclipse Process Framework Software Development Process”,
Rational Unified Process (RUP) - IBM / Rational Software Development Process,
Oracle Unified Method (OUM) - Oracle fejlesztési és megvalósítási folyamat,
Rational Unified Process-System Engineering (RUP-SE) - A RUP egy verziója - Rational Software a System Engineering számára.
A RAD a Rapid Application Development szavak első betűi, gyors
alkalmazásfejlesztésnek fordítható. James Martin (1933-2013) dolgozta ki az 1980-as években.
Forrás - Source: www.szit.hu
Jellemzői:
iterációs fejlesztés
működő prototípusok létrehozása
fejlesztést támogató programok használata, például IDE
IDE (Integrated Development Environment - Integrált fejlesztői környezet)
szerkesztő
fordító
nyomkövető
automatizált fordítás
esetleg vizuális szerkesztő (GUI - Grapfical User Interface)
IDE megvalósítások
Geany
Scite
XEmacs, GNU Emacs
Anjuta (Lin)
Eclipse
CodeBlocks
MonoDevelop
KDevelop (Lin)
NetBeans
Visual Studio (Visual Basic)
Delphi
Lazarus
Hátrányai:
nagy méretű a futtatható program
lassú a futtatható program
A szoftverfejlesztés során a felhasználókkal folyamatos egyeztetés folyik, így
a fejlesztők nem találkoznak hirtelen jött ötletekkel, módosításokkal, a
félreértések ilyen módon minimalizálódnak.
Forrás - Source:
agilelucero.com
Az előírt 4 tevékenység:
kódolás,
tesztelés,
kapcsolat a megrendelővel,
tervezés.
Jellemző technikák:
páros programozás,
tesztvezérelt fejlesztés,
kódáttekintés,
folyamatos integráció - a részeket (modulokat) folyamatosan próbáljuk meg beépíteni az egészbe,
kódszépítés.
A projekthez az egész fejlesztői gárda együtt dolgozik. A fejlesztő csapattal együtt dolgozik az ügyfél egy képviselője. A csapat az üzleti érték előállításán dolgozik. Folyamatosan kisebb egységeket adnak ki, amelyek teljesítik az ügyfél elvárásait.
A scrum egy projektmenedzsment módszertan, az
agilis szoftverfejlesztés egyik
megvalósítása. A scrum-ban egy szoftver elkészítését körülbelül 2 hetes
fázisokra osztjuk. Ezeket sprint-eknek nevezzük. Minden sprint elején
van egy értekezlet és minden sprint végén a fejlesztők megbeszélik, mi
az, amit sikerült megvalósítani és mi az, amit nem, valamint mely teendők
vannak még hátra.
A scrum-módszerben minden reggel egy rövid, 15 perces megbeszéléssel
kezdődik, amelyben a fejlesztők megbeszélik, hogy ki milyen munkát végzett el,
mi az, ami nem sikerült és mit tervez.
Ezek a reggeli megbeszélések fontosak, hogy állva történjenek, mert másként elmehet rá az idő.
Forrás - Source:
www.szit.hu
A scrum-nak mindig van egy mestere, aki vezeti a megbeszéléseket. Ezek alkalmával a résztvevőknek a következő kérdésekre kell válaszolniuk:
Mit csináltál a tegnapi megbeszélés óta?
Mi az, amit nem sikerült megvalósítani tegnap óta?
Mit fogsz csinálni a következő megbeszélésig?
Disznók:
Scrum mester (Scrum Master)
Terméktulajdonos (Product Owner)
Csapat (Team)
Csirkék:
Üzleti szereplők (Stakeholders)
Menedzsment (Managers)
Egy folyamatosan frissített mágneses, parafa vagy egyéb tábla, amelyen
oszlopokra bontva megtaláljuk a tennivalókat, a folyamatban lévő munkákat és a
már kész munkákat. Természetesen az egyes részek még több oszlopra bonthatók.
Forrás - Source: www.szit.hu
A táblát folyamatosan frissíteni kell a teendők (ToDo), folyamatban
lévő (In progress) és kész dolgok (Done) listájával. Fontos,
hogy a folyamatban lévő dolgok között háromnál több dolog nem szerepelhet!
A felülről számított 3. táblában az In progress és Testing után
lévő szám azt jelenti, hogy hány dolog lehet maximálisan folyamatban.
Taiichi Ohno (1912-1990) ötletei után vették át a szoftverfejlesztők, aki
mérnökként a Toyota Termelési Rendszer (TPS) atyja volt. A Lean-menedzsment a következő általános megállapításokat teszi az optimális
munkavégzésre vonatkozóan:
Forrás - Source: www.szit.hu
Forrás - Source: www.szit.hu
A 5W, 5 kérdést jelent, amelyet mindig úgy kezdünk „Miért …”
Például:
Miért nem készítetted el a modult? - Nincs kész az adatbázis.
Miért nincs kész az adatbázis? - Az adatbázis-fejlesztő nem kapta meg az adatokat.
Miért nem kapta meg az adatbázis-fejlesztő az adatokat? - A szerver áll.
Miért áll a szerver? - Hiányzik egy alkatrész a szerverből.
Miért hiányzik az alkatrész a szerverből? - A gazdasági igazgató nem hajlandó aláírni a beszerzést.
Taiichi Ohno ötletei alapján a szoftverfejlesztésben a következőket vesszük figyelembe:
Forrás - Source: www.szit.hu
A 2000-es évektől már igen elterjedt kódfejlesztési módszer (TDD - Test-Driven Development - Tesztvezérelt fejlesztés).
A TDD lényege, hogy nem a funkció kódírásával kezdjük, hanem a funkciót tesztelő kód megírásával.
Szokatlan megközelítés, de természetesen van mélyebb értelme, hiszen a teszt megfogalmazása, implementálása során fedezhetjük fel a funkció elvárt működésének sajátosságait. Ezáltal a tesztek nemcsak tesztkörnyezetként, hanem specifikációként, dokumentációként is szolgálhatnak.
Ugyanakkor a tesztkód implementálása során határozhatjuk meg, választhatjuk szét egymástól a feladatfunkciókat. Ezáltal lehetőségünk nyílik arra, hogy kisebb lépésekben haladjunk, amely a kódírásban egyértelmű minőségjavulást eredményez. Egyes ajánlások már 10-20 kódsor után javasolják az automata tesztek lefuttatását.
A tesztmegírás után az új tesztet a többivel együtt futtatjuk le, ekkor azt vizsgáljuk, hogy új tesztünk sikeres lesz-e vagy elbukik. Ha sikeres, az voltaképpen rossz, hiszen még le sem kódoltuk a funkciót, ennek ellenére jó eredményt kaptunk.
Csakis abban az esetben kezdhetünk hozzá az új kód megírásához, ha az új tesztkód a vártak szerint elbukott. Ezután a kódolás már egyértelműen célorientált: pontosan annyi kódot kell implementálnunk, hogy a tesztkód sikeressé váljon.
Ha kódfuttatásunk mindezek után sikeres lesz, majdhogynem bizonyosak lehetünk abban, hogy az új funkció a lehető legkorrektebb feltételek között működik. Ezután az új funkciót kényelmesen és biztonságosan beilleszthetjük a konkrét kódkörnyezetbe a refaktorálás segítségével.
A szakirodalom ezt az összetett, előzetes kódautomatikával támogatott folyamatot Red - Green - Refactor néven említi.
Forrás - Source: www.szit.hu
A TDD-módszer használata legtöbbször nem előírás a szoftvercégen belül. Néhol a fejlesztőre van bízva esetleges használata, máshol viszont projektszintű követelmény, ám az bizonyos, hogy a megírt kódot mindenféleképpen tesztelni kell, sőt, komolyabb projektek esetén a teszteredményeket dokumentálni is szükséges.
A latin eredetű agilis szó jelentése szerint: életrevaló, serény, tevékeny, mozgékony, ügyes, hatékony.
A megrendelő legtöbbször maga sem tudja, hogy mit akar. Az igényei
folyamatosan változnak. Mindezek miatt egy rugalmas, gyorsan reagáló
szoftverfejlesztési módszerre van szükség.
Agilis módszertanok:
stb.
Az agilis kiáltvány (idézet):
Legfontosabbnak azt tartjuk, hogy az ügyfél elégedettségét a működő szoftver mielőbbi és folyamatos szállításával vívjuk ki.
Elfogadjuk, hogy a követelmények változhatnak, akár a fejlesztés vége felé is. Az agilis eljárások a változásból versenyelőnyt kovácsolnak az ügyfél számára.
Szállíts működő szoftvert gyakran, azaz néhány hetenként vagy havonként, lehetőség szerint a gyakoribb szállítást választva.
Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt minden nap, a projekt teljes időtartamában.
Építsd a projektet sikerorientált egyénekre. Biztosítsd számukra a szükséges környezetet és támogatást és bízz meg bennük, hogy elvégzik a munkát.
A leghatásosabb és leghatékonyabb módszer az információ átadásának a fejlesztési csapaton belül a személyes beszélgetés.
A működő szoftver az elsődleges mércéje az előrehaladásnak.
Az agilis eljárások a fenntartható fejlesztést pártolják. Fontos, hogy a szponzorok, a fejlesztők és a felhasználók folytonosan képesek legyenek tartani egy állandó ütemet.
A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást.
Elengedhetetlen az egyszerűség, azaz az elvégezetlen munkamennyiség maximalizálásának művészete.
A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatoktól származnak.
A csapat rendszeresen mérlegeli, hogy miképpen lehet emelni a hatékonyságot, és ehhez hangolja és igazítja az működését.
Pénzes László