szit

Ez az oldal csak olvasható. Megtekintheted a forrását, de nem változtathatod meg. Ha úgy gondolod, hogy ez helytelen, kérdezd az Adminisztrátorokat!
[[oktatas:programozás|< Programozás]]

====== Fejlesztési modellek és módszertanok ======

  * **Szerző:** Sallai András
  * Copyright (c) Sallai András, 2014, 2022
  * Licenc: [[https://creativecommons.org/licenses/by-sa/4.0/|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. 

{{:oktatas:programozás:vizesesmodell_03.png|}}


  * 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

{{:oktatas:programozás:evolucios_modell.png?200|}}


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.

{{:oktatas:programozás:inkrementalis_fejlesztes.png|}}

===== 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.

{{:oktatas:programozás:spiralis_modell.png?200|}}

{{:oktatas:programozás:spiralismodell.png?400|}}

===== 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.

{{:oktatas:programozás:v-modell.png|}}

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


{{:oktatas:programozas:v-modell_uj.png|}}

===== 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 módszert a **Rational Software Corporation** fejlesztette. A céget később az IBM felvásárolta.
A RUP egy agilis megközelítés. Az [[oktatas:programozás:uml|UML]] és az [[wp>Unified_Process|USDP]] alapján készült.



{{:oktatas:programozás:rup_eredete.png|}}



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ő**

{{:oktatas:programozás:rup_modell.png|}}


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ú**

{{:oktatas:programozás:rad.png|}}

===== 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.


{{:oktatas:programozás:extrem_programozas.png|}}

===== 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)
  * {{:oktatas:programozás:scrum.png|}}



===== 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.

{{:oktatas:programozás:lean.png|}}



  * 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.

{{:oktatas:programozás:tps.png|}}


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.

{{:oktatas:programozás:leanmodell.png|}}

===== 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.

{{:oktatas:programozás:tdd.png?300|}}



===== 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.