< Programozás

Fejlesztési modellek és módszertanok

Szerző: Sallai András

Copyright © Sallai András, 2014, 2022

Licenc: CC Attribution-Share Alike 4.0 International

Web: https://szit.hu

Bevezetés

A fejlesztés folyamatával kapcsolatos témakörök, fejlesztési modellek.

Kezdetben csak elemeztünk, terveztünk, kódoltunk, teszteltünk és terjesztettünk. Ez tekintettük a szoftverfejlesztés megfelelő modelljének. Mára többféle szoftverfejlesztési modell jött létre. Hatékonyabbnál hatékonyabb fejlesztési modellek alakultak ki.

Vízesés modell

A legrégebbi fejlesztési modell, fázismodellnek is hívják. Az egyes fázisokra nincs visszatérés. Az egész fejlesztés, egyetlen szekvenciális folyamat. Ez persze a gyakorlatban nem működik. A kényszerű visszatérés annál költségesebb minél nagyobbat kell visszalépni.

Ritkán használjuk, esetleg nagyobb egyedi szoftverek fejlesztése esetén.

Elsőként Winston W. Royce írta le a modellt.

Előre megköveteli az ügyféltől, hogy véglegesítse a követelményeket.

A fejlesztőtől, megköveteli, hogy előre válasszon ki egy tervezési stratégiát.

Előnye: Egyszerűen menedzselhető.

Hátránya: Nagy és bonyolult rendszerek jöhetnek létre, amelyek alkalmatlanok a változtatásra.

Evolúciós modell

Készítünk egy kezdeti megvalósítást.

Véleményeztetjük a felhasználóval.

Finomítás

Jellemzők:

sok verzió

párhuzamosság

gyors visszacsatolás

Tervezéssel kapcsolatos döntések elmaradnak. Eredménye nehezen érthető szoftver, gyenge felépítés.

Inkrementális fejlesztés

Valahol a vízesés és az evolúciós fejlesztés között.

Elsőként egy vázlatos követelményrendszert állítunk össze.

Osztályozzuk a szolgáltatásokat fontosság szerint.

A fontosakat elkezdjük megvalósítani.

Több változatot hozunk létre, alváltozatokra osztva a fejlesztést. Az egyes változatokat is több lépésben hozzuk létre.

Spirális modell

1986-ban Boehm javasoja.

Nem tevékenységek és visszalépések sorozata, inkább spirál.

Fejlesztés négy lépcsőben, ciklikusan.

Minden ciklus célkitűzéssel indul.

Iteratív modell

Iteratív vagy folyamatiterációs modell.

A fejlesztést rendszeresen ismétlődő tevékenységnek tekintjük.

Kis inkrementációs lépésekből áll.

A specifikáció a szoftverrel együtt készül, nem előre.

V-modell

A német védelmi minisztérium dolgozta ki.

A korai fejlesztések egyike

Nem csak modell, ez már módszertan is.

Biztonságkritikus számítógépek fejlesztésénél terjedt el.

A sorrend nem szigorúan van véve.

Az eredeti V-modell-t mostanában többféleképpen értelmezik.

Tisztaszoba

Angolosan cleanroom.

A tisztaszoba technika magas színvonalú, hitelesíthető szoftverek fejlesztésénél használt eljárás.

A tisztaszoba technikát Harlan Mills használta az IBM berkeiben.

A hangsúly a hibák eltávolítása helyett azok megelőzésén van.

Egy egész csapat ellenőrzi, hogy a tervezés helyes úton jár-e.

Fokozatos fejlesztés, iteratív megközelítéssel.

Előremeghatározott szabványokban mérik a munkafolyamat előrehaladását.

A tesztelést mintegy statisztikai eljárást hajtják végre.

RUP

A Rational Unified Process szavak rövidítése.

A Rational Software Corporation fejlesztette, amit később az IBM felvásárolt. Egy agilis megközelítés. Az UML és az USDP alapján készült.

Igyekszik több folyamatmodellt ötvözni.

Jellemzők:

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 mérföldkő

Az USDP-t (vagy UP) más variációi is létrejöttek:

Agile Unified Process (AUP)

variáció - Scott W. Ambler

Basic Unified Process (BUP)

variáció - IBM az OpenUP előfutára

Enterprise Unified Process (EUP)

a Rational Unified Process kiterjesztése

Essential Unified Process (EssUP)

variáció - Ivar Jacobson

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

RAD

A RAD, Rapid Application Development szavak első betűi. Gyors alkalmazásfejlesztésnek fordítható.

A James Martin dolgozta ki, az 1980-as években.

Jellemzők:

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

IDE eszközei

szerkesztő

fordító

nyomkövető

fordítás automatizált

esetleg vizuális szerkesztő (GUI-hoz)

IDE megvalósítások

Eclipse

CodeBlocks

MonoDevelop

KDevelop (Lin)

NetBeans

Visual Studio (Visual Basic)

Delphi

Lazarus

Bírálat:

futtatható program nagy méretű

futtatható program lassú

Extrém programozás

Egy szoftverfejlesztése 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 minimalizálódnak.

Előírt négy tevékenység:

kódolás

tesztelés

kapcsolat a megrendelővel

tervezés

Jellemző technikák:

páros programozás

teszt-vezérelt fejlesztés

kód áttekintés

folyamatos integráció - a részeket (modulokat) folyamatosan megpróbáljuk 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 nap mint nap 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, amely teljesíti az ügyfél elvárásait.

Scrum

A scrum egy projektmenedzsment módszertan.

Az agilis szoftverfejlesztés egyik megvalósítása.

A scrumban egy szoftver elkészítését körülbelül kéthetes fázisokra osztjuk. Ezeket sprinteknek 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, mi az amit nem és mi az ami hátra van.

A scrum módszerben minden reggel is egy rövid 15 perces megbeszéléssel kezdődik, amelyben a fejlesztők megbeszélik ki milyen munkát végzett el, mi az ami nem sikerült és mit tervez. Ezek a reggeli megbeszélések fontos, hogy állva történjenek, mert másként elmehet az idő.

A scrumban van egy scrum mester, aki vezeti a megbeszéléseket. A megbeszélések alkalmával a következő kérdésekre kell válaszolniuk a a résztvevőknek:

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)

Kanban

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. Az egyes részek persze még több oszlopra bonthatók.

Todo	Process	Ready
naplózás	azonosítás	adatbázis-elérés
Backlog	New	In progress	Complete
naplózás	azonosítás	adatbázis-elérés
Backlog	New	In progress [4]	Testing [3]	Complete
naplózás	azonosítás	adatbázis-elérés
ToDo	Design [2]	Devel [2]	Q4 [3]	Done
naplózás	azonosítás	adatbázis-elérés
Tennivalók	Folyamatban	Elkészült
Tervezés	Fejlesztés	Tesztelés	Telepítés
belépés naplózás utalás felhasználó-kezelés csoportok kezelése

A táblát folyamatosan frissíteni kell a teendők, folyamatban lévő és kész dolgok listájával. Fontos, hogy a folyamatban lévő dolgok között háromnál több dolog nem szerepelhet.

A harmadik táblában az „In progress” után a szám azt jelenti, hány dolog lehet maximálisan folyamatban, mint a „Testing” után is.

Lean módszer

Kiejtve: [liːn]

Egy fejlesztési módszertan. Taiichi Ohno ötletei után vették át a szoftverfejlesztők.

Taiichi Ohno (大野 耐一) a Toyota Termelési Rendszer (TPS) atyja.

A munkahelyek kialakítására Ohno kitalálta az 5S-t.

A munkahelyi problémák felderítésére kitalálta az 5W-t.

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 Plútó nevű szerver áll.

Miért áll a Plútó nevű 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 figyelemben.

TDD

A TDD a Test Driven Development szavakból alkotott betűszó, amely teszt vezérelt fejlesztésként fordítható.

Nem egy tesztelési módszer. Helyette egy fejlesztési modell. Igaz automatizált teszteket írunk, de az automatizált teszt használatától még nem lesz teszt vezérelt egy fejlesztés.

A teszt vezérelt fejlesztés menete:

Előbb írok egy tesztet ami hibával leáll.

Ha egy nem létező osztályra hivatkozunk és ezért nem fordul le a teszt már elég.

Ez után éppen csak annyi kódot írok, hogy a teszt teljesüljön.

Újratervezem a kódot, majd kezdem az első lépéstől.

Az utolsó lépés után megint tesztet írok, majd annyi kódot, hogy a teszt teljesüljön, újratervezek. Így megy ez ciklikusan.

Agilis szoftverfejlesztés

A megrendelő legtöbbször maga sem tudja mit akar. Az igényei folyamatosan változnak. Mindezek miatt, egy rugalmas szoftverfejlesztési módszerre van szükség.

Agilis módszertanok:

Scum

Kanban

Lean

stb.

Az agilis kiáltvány:

http://agilemanifesto.org/

A fenti oldalról 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.