A szoftverfejlesztési életciklus (SDLC) a projektmenedzsmentben használt spirituális modell, amely meghatározza az információs rendszerfejlesztési projekt szakaszait, a kezdeti megvalósíthatósági tanulmánytól az elkészült alkalmazás karbantartásáig.

Különféle szoftverfejlesztési életciklus modellek határozzák meg és tervezik, amelyeket a szoftverfejlesztési szakaszban követnek. Ezeket a modelleket más néven ' Szoftverfejlesztési folyamatmodellek .' Minden folyamatmodell egy saját típusának megfelelő fázissorozatot követ, hogy a szoftverfejlesztési lépésben sikeres legyen.

Íme az SDLC életciklusának néhány fontos fázisa:

Vízesés modell

A vízesés egy általánosan elfogadott SDLC modell. Ennél a módszernél a szoftverfejlesztés teljes folyamata különböző fázisokra oszlik.

A vízesés modell egy folyamatos szoftverfejlesztési modell, amelyben a fejlesztés folyamatosan lefelé folyik (mint egy vízesés) a követelményelemzés, a tervezés, a megvalósítás, a tesztelés (validáció), az integráció és a karbantartás lépésein keresztül.

A tevékenységek lineáris rendezése jelentős következményekkel jár. Először is, egy fázis végének és a következő kezdetének azonosításához az egyes lépések végén bizonyos tanúsítási technikákat kell alkalmazni. Egyes ellenőrzések és érvényesítések általában azt jelentik, hogy a szakasz kimenete összhangban van a bemenetével (ami az előző lépés kimenete), és hogy a szakasz kimenete összhangban van a rendszer általános követelményeivel.

RAD modell

A RAD vagy a Rapid Application Development folyamat a vízesés modell átvétele; rövid időn belüli szoftverfejlesztést céloz meg. A RAD modell azon az elgondoláson alapul, hogy a rendszerkövetelmények összegyűjtésére fókuszcsoportok használatával rövidebb idő alatt jobb rendszert lehet kifejleszteni.

• Üzleti modellezés
• Adatmodellezés
• Folyamatmodellezés
• Alkalmazásgenerálás
• Tesztelés és forgalom

Spirál modell

A spirálmodell a kockázatvezérelt folyamatmodell . Ez az SDLC-modell segít a csoportnak egy vagy több folyamatmodell elemeinek átvételében, mint például a vízesés, a növekményes, a vízesés stb. A spiráltechnika a gyors prototípuskészítés és a tervezési és fejlesztési tevékenységek párhuzamosságának kombinációja.

A spirál minden egyes ciklusa az adott ciklus céljainak, a célok elérésének lehetséges alternatíváinak és a fennálló korlátoknak az azonosításával kezdődik. Ez a ciklus első negyede (bal felső kvadráns).

A ciklus következő lépése a különböző alternatívák értékelése a célok és korlátok alapján. Ebben a lépésben az értékelés középpontjában a projekt kockázati megítélése áll.

A következő lépés olyan stratégiák kidolgozása, amelyek megoldják a bizonytalanságokat és a kockázatokat. Ez a lépés olyan tevékenységeket foglalhat magában, mint a teljesítményértékelés, a szimuláció és a prototípus-készítés.

V-modell

Az ilyen típusú SDLC modell tesztelésben és a fejlesztésben a lépést párhuzamosan tervezzük. Tehát vannak ellenőrző fázisok az oldalon, és érvényesítési fázis a másik oldalon. A V-Model kódolási fázissal csatlakozik.

Növekményes modell

A növekményes modell nem különálló modell. Ez szükségszerűen vízesési ciklusok sorozata. A követelményeket a projekt kezdetén csoportokra osztják. Minden csoport esetében az SDLC modellt követik a szoftver fejlesztése. Az SDLC folyamat megismétlődik, és minden egyes kiadás több funkciót ad hozzá, amíg az összes követelmény teljesül. Ebben a módszerben minden ciklus az előző szoftverkiadás karbantartási fázisaként működik. A növekményes modell módosítása lehetővé teszi a fejlesztési ciklusok átfedését. Ezt követően a következő ciklus megkezdődhet, mielőtt az előző ciklus befejeződik.

Agilis modell

Az agilis módszertan egy olyan gyakorlat, amely elősegíti a fejlesztés és a tesztelés folyamatos interakcióját bármely projekt SDLC folyamata során. Az Agilis módszerben a teljes projektet kis növekményes buildekre osztják. Mindezek a buildek iterációban állnak rendelkezésre, és minden iteráció egy-három hétig tart.

Bármely agilis szoftver fázist úgy jellemeznek, hogy a szoftverprojektek nagy részével kapcsolatban több kulcsfontosságú feltételezés is figyelembe vehető:

1. Nehéz előre meggondolni, hogy mely szoftverkövetelmények maradnak fenn és melyek változnak. Ugyanilyen nehéz megjósolni, hogyan változnak a felhasználói prioritások a projekt előrehaladtával.
2. Sok szoftvertípus esetében a tervezés és a fejlesztés össze van kötve. Ez azt jelenti, hogy mindkét tevékenységet párhuzamosan kell végrehajtani, hogy a tervezési modellek bizonyítást nyerjenek a létrehozásuk során. Nehéz belegondolni, hogy mennyi tervezésre van szükség, mielőtt az építést a konfiguráció tesztelésére használnák.
3. Az elemzés, a tervezés, a fejlesztés és a tesztelés nem olyan kiszámítható (tervezési szempontból), mint azt szeretnénk.

Iteratív modell

Ez a szoftverfejlesztési életciklus egy sajátos megvalósítása, amely egy kezdeti, egyszerűsített megvalósításra összpontosít, amely azután fokozatosan egyre összetettebbé és szélesebb szolgáltatáskészletté válik, amíg a rendszer elkészül. Röviden, az iteratív fejlesztés egy módja annak, hogy egy nagy alkalmazás szoftverfejlesztését kisebb darabokra bontsuk.

Big bang modell

Az ősrobbanás-modell a szoftverfejlesztés és -kódolás minden típusú erőforrására összpontosít, tervezés nélkül vagy nagyon kevéssé. A követelményeket megértik és végrehajtják, amikor jönnek.

Ez a modell a legjobban olyan kis projekteknél működik, amelyek kisebb méretű fejlesztőcsapattal dolgoznak együtt. Akadémiai szoftverfejlesztési projektekhez is hasznos. Ideális modell, ahol a követelmények vagy ismeretlenek, vagy nincs megadva a végleges megjelenési dátum.

Prototípus modell

A prototípus-modell a követelmények összegyűjtésével kezdődik. A fejlesztő és a felhasználó találkozik és meghatározza a szoftver célját, azonosítja az igényeket stb.

A ' gyors tervezés ' akkor jön létre. Ez a kialakítás a szoftver azon szempontjaira összpontosít, amelyek a felhasználó számára láthatóak lesznek. Ezután egy prototípus kifejlesztéséhez vezet. Az ügyfél ezután ellenőrzi a prototípust, és minden szükséges módosítást vagy változtatást végrehajt a prototípuson.

Ebben a lépésben a hurkolásra kerül sor, és a prototípus jobb verziói készülnek. Ezek folyamatosan megjelennek a felhasználó számára, így az esetleges új változások frissíthetők a prototípusban. Ez a folyamat addig folytatódik, amíg az ügyfél elégedett nem lesz a rendszerrel. Ha a felhasználó elégedett, a prototípust a minőségi és biztonsági szempontok figyelembevételével a tényleges rendszerré alakítják.