logo

Agilis modell

Az agilis jelentése gyors vagy sokoldalú. Agilis folyamatmodell Az iteratív fejlesztésen alapuló szoftverfejlesztési megközelítésre utal. Az agilis módszerek kisebb iterációkra bontják a feladatokat, vagy a részek nem tartalmaznak közvetlenül hosszú távú tervezést. A projekt terjedelmét és követelményeit a fejlesztési folyamat elején határozzák meg. Az iterációk számára, időtartamára és terjedelmére vonatkozó tervek egyértelműen előre meghatározottak.

Az Agilis folyamatmodellben minden iterációt rövid idő „keretnek” tekintünk, amely jellemzően egy-négy hétig tart. A teljes projekt kisebb részekre bontása segít minimalizálni a projekt kockázatát és csökkenteni a teljes projekt szállítási időigényét. Minden iterációban egy csapat dolgozik a teljes szoftverfejlesztési életcikluson, beleértve a tervezést, a követelmények elemzését, a tervezést, a kódolást és a tesztelést, mielőtt a működő terméket bemutatják az ügyfélnek.

Agilis modell

Az agilis modell fázisai:

A következő fázisok az Agilis modellben a következők:

  1. Követelmények összegyűjtése
  2. Tervezd meg a követelményeket
  3. Konstrukció/ iteráció
  4. Tesztelés/ Minőségbiztosítás
  5. Telepítés
  6. Visszacsatolás

1. Követelmények összegyűjtése: Ebben a fázisban meg kell határoznia a követelményeket. Ismertesse az üzleti lehetőségeket, és tervezze meg a projekt felépítéséhez szükséges időt és erőfeszítést. Ezen információk alapján értékelheti a műszaki és gazdasági megvalósíthatóságot.

rendszer szoftver

2. Tervezze meg a követelményeket: Miután azonosította a projektet, dolgozzon együtt az érdekelt felekkel a követelmények meghatározásában. A felhasználói folyamatábra vagy a magas szintű UML diagram segítségével bemutathatja az új szolgáltatások működését, és megmutathatja, hogy azok hogyan vonatkoznak majd a meglévő rendszerre.

3. Felépítés/ iteráció: Amikor a csapat meghatározza a követelményeket, kezdődik a munka. A tervezők és a fejlesztők elkezdenek dolgozni projektjükön, amelynek célja egy működő termék bevezetése. A termék különböző fejlesztési szakaszokon megy keresztül, így egyszerű, minimális funkcionalitást tartalmaz.

4. Tesztelés: Ebben a fázisban a minőségbiztosítási csapat megvizsgálja a termék teljesítményét, és keresi a hibát.

nyilatkozat nyomtatása java nyelven

5. Üzembe helyezés: Ebben a fázisban a csapat kiad egy terméket a felhasználó munkakörnyezete számára.

6. Visszajelzés: A termék kiadása után az utolsó lépés a visszajelzés. Ebben a csapat visszajelzést kap a termékről, és a visszajelzéseken keresztül dolgozik.

Agilis tesztelési módszerek:

  • Dulakodás
  • Kristály
  • Dinamikus szoftverfejlesztési módszer (DSDM)
  • Funkcióvezérelt fejlesztés (FDD)
  • Lean szoftverfejlesztés
  • extrém programozás (XP)

Dulakodás

A SCRUM egy agilis fejlesztési folyamat, amely elsősorban a feladatok csapatalapú fejlesztési körülmények között történő kezelésére összpontosít.

Három szerepkör van benne, és feladataik a következők:

    Scrum mester:A scrum felállíthatja a mestercsapatot, megszervezheti a találkozót és elháríthatja a folyamat akadályaitTerméktulajdonos:A terméktulajdonos elkészíti a termékhátralékot, priorizálja a késleltetést, és felelős a funkciók elosztásáért minden ismétlésnél.Scrum csapat:A csapat irányítja a munkáját és megszervezi a munkát a sprint vagy a kerékpározás teljesítése érdekében.

extrém programozás (XP)

Ezt a módszert akkor alkalmazzák, amikor az ügyfelek folyamatosan változtatják az igényeket vagy követelményeket, vagy ha nem biztosak a rendszer teljesítményében.

ábécé számokkal

Kristály:

Ennek a módszernek három fogalma van:

javascript mintakód példák
  1. Chartering: Ebben a fázisban több tevékenység is részt vesz, mint például egy fejlesztői csapat létrehozása, megvalósíthatósági elemzések elvégzése, tervek kidolgozása stb.
  2. Ciklikus szállítás: ez alatt további két ciklus áll, ezek:
    • A csapat frissíti a kiadási tervet.
    • Az integrált termék eljut a felhasználókhoz.
  3. Összefoglaló: A felhasználói környezetnek megfelelően ez a fázis végzi a telepítést, az utótelepítést.

Dinamikus szoftverfejlesztési módszer (DSDM):

A DSDM egy gyors alkalmazásfejlesztési stratégia szoftverfejlesztéshez, és agilis projektelosztási struktúrát biztosít. A DSDM alapvető jellemzői, hogy a felhasználóknak aktívan kapcsolódniuk kell, és a csapatok döntési jogot kaptak. A DSDM-ben használt technikák a következők:

  1. Időboksz
  2. Moszkva szabályok
  3. Prototípuskészítés

A DSDM projekt hét szakaszból áll:

  1. Előprojekt
  2. Megvalósíthatósági tanulmány
  3. Üzleti tanulmány
  4. Funkcionális modell iteráció
  5. Iteráció tervezése és kivitelezése
  6. Végrehajtás
  7. Projekt után

Funkcióvezérelt fejlesztés (FDD):

Ez a módszer a „Tervezés és építés” funkciókra összpontosít. Más intelligens módszerekkel ellentétben az FDD a munka apró lépéseit írja le, amelyeket funkciónként külön-külön kell megszerezni.

Lean szoftverfejlesztés:

A karcsú szoftverfejlesztési módszertan az „éppen időben történő gyártás” elvét követi. A lean módszer a szoftverfejlesztés növekvő sebességét és a költségek csökkenését jelzi. A lean fejlődés hét fázisban foglalható össze.

  1. Hulladék megszüntetése
  2. A tanulás felerősítése
  3. A kötelezettségvállalás elhalasztása (a lehető legkésőbbi döntés)
  4. Korai szállítás
  5. A csapat felhatalmazása
  6. Integritás építése
  7. Optimalizálja az egészet

Mikor használjuk az Agilis modellt?

  • Amikor gyakori változtatásokra van szükség.
  • Amikor egy magasan képzett és tapasztalt csapat áll rendelkezésre.
  • Amikor az ügyfél folyamatosan készen áll egy találkozóra a szoftvercsapattal.
  • Ha a projekt mérete kicsi.

Az agilis módszer előnyei (előnyei):

  1. Gyakori szállítás
  2. Szemtől szembeni kommunikáció az ügyfelekkel.
  3. Hatékony tervezés és megfelel az üzleti követelményeknek.
  4. A változtatások bármikor elfogadhatók.
  5. Csökkenti a teljes fejlesztési időt.

Az agilis modell hátrányai (hátrányai):

  1. A formális dokumentumok hiánya miatt ez zavart kelt, és a különböző fázisok során meghozott döntő döntéseket a csapat különböző tagjai bármikor félreértelmezhetik.
  2. A megfelelő dokumentáció hiánya miatt a projekt befejezése és a fejlesztők másik projekthez való hozzárendelése után a kész projekt karbantartása nehézségekbe ütközhet.