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