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

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.

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.

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

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.

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

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

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.

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

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ú

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.

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)
• 

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.

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.

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:

1. Miért nem készítetted el a modult? - Nincs kész az adatbázis.
2. Miért nincs kész az adatbázis? - Az adatbázis-fejlesztő nem kapta meg az adatokat.
3. Miért nem kapta meg az adatbázis-fejlesztő az adatokat? - A Plútó nevű szerver áll.
4. Miért áll a Plútó nevű szerver? - Hiányzik egy alkatrész a szerverből.
5. 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.

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.

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:

1. 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.
2. 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.
3. 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.
4. Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt minden nap, a projekt teljes időtartamában.
5. É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.
6. 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.
7. A működő szoftver az elsődleges mércéje az előrehaladásnak.
8. 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.
9. A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást.
10. Elengedhetetlen az egyszerűség, azaz az elvégezetlen munkamennyiség maximalizálásának művészete.
11. A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatoktól származnak.
12. 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.