Rendszerfejlesztési életciklus

A rendszerfejlesztésben, az információs rendszerekben és a szoftverfejlesztésben a rendszerfejlesztési életciklus (SDLC – Systems Development Life Cycle), másnéven alkalmazásfejlesztési életciklus egy információrendszer tervezésére, létrehozására, tesztelésére és telepítésére szolgáló folyamat. A rendszerfejlesztési életciklus-koncepció számos hardver- és szoftverkonfigurációra vonatkozik, mivel a rendszer csak hardverből vagy szoftverből, illetve ezek kombinációjából állhat. Ebben a ciklusban általában hat szakasz van: követelményelemzés, tervezés, fejlesztés, tesztelés, megvalósítás, dokumentáció és értékelés.

Áttekintés

A rendszerfejlesztési életciklus számos egyértelműen meghatározott és különálló munkafázisból áll, amelyeket a rendszermérnökök és rendszerfejlesztők információs rendszerek tervezésére, építésére, tesztelésére és szállítására használnak. Mint bármi, amit egy futószalagon gyártanak, az SDLC célja is az, hogy olyan kiváló minőségű rendszereket állítson elő, amelyek megfelelnek vagy meghaladják az ügyfelek elvárásait, az ügyfelek igényei alapján, olyan rendszerek biztosításával, amelyek minden egyértelműen meghatározott fázison áthaladnak, az ütemezett időkereteken és költségbecsléseken belül. A számítógépes rendszerek összetettek, és gyakran (különösen a szolgáltatásorientált architektúra közelmúltbeli növekedésével) több hagyományos rendszert kapcsolnak össze, amelyeket különböző szoftvergyártók szolgáltatnak. Az ilyen összetettségi szint kezeléséhez számos SDLC modellt vagy módszertant hoztak létre, például vízesés, spirál, agilis szoftverfejlesztés, gyors prototípuskészítés, lépésenkénti, szinkronizálás és stabilizálás.

Az SDLC az agilis és iteratív és szekvenciális módszerek spektrumán írható le. Agilis módszerek, mint például az extrém programozás (XP) és a scrum, könnyű folyamatok, amelyek lehetővé teszik a gyors változásokat (amellett, hogy követi az SLDC szerinti mintát) a fejlesztési ciklus mentén. Az iteratív módszerek, mint például a Rational Unified Process (RUP) és a Dynamic Systems Development Method (DSDM), a korlátozott projekt hatókörre összpontosítanak, és több ismétléssel bővítik vagy fejlesztik a termékeket. Szekvenciális vagy Big Design-Up-Front (BDUF) modellek, mint például a vízesés, a teljes és helyes tervezésre összpontosítanak, hogy a nagy projekteket és a kockázatokat a sikeres és kiszámítható eredményekhez irányítsák. Más modellek, mint például az anamorfikus fejlesztés, hajlamosak egyfajta fejlődésre összpontosítani, amely vezérli a projekt hatályát és az adaptív iterációkat a funkció fejlesztésben.

A projektmenedzsmentben a projekt meghatározható mind a projekt életciklusával (PLC), mind az SDLC-vel, amelynek során némileg eltérő tevékenységek történnek. Taylor (2004) szerint, "a projekt életciklusa magában foglalja a projekt összes tevékenységét,míg a rendszerfejlesztési életciklus a termék követelményeinek megvalósítására összpontosít ".

Egy informatikai projekt fejlesztése során rendszerfejlesztési életciklust (SDLC) használnak, amely részletesen leírja a projekt különböző szakaszait a tervező táblától a projekt befejezéséig.

Az SDLC önmagában nem módszertan, inkább csak egy leírás a szoftveralkalmazás életciklusának fázisairól. Ezek a fázisok (általánosságban) a következők: vizsgálat, elemzés, tervezés, építés, tesztelés, megvalósítás, karbantartás és támogatás. Minden szoftverfejlesztési módszer (mint például a közismertebb vízesés és scrum módszerek) követi az SDLC fázisokat, de ennek módjai nagymértékben eltérnek a módszerek között. A Scrum keretrendszerben például mondhatjuk, hogy egyetlen felhasználó által készített terv az SDLC összes fázisán áthalad egy kéthetes sprinten belül. Ezzel szemben a vízesés módszertan egy másik példa, ahol minden üzleti követelményről (amelyet az SDLC elemzési szakaszában egy üzleti követelmény specifikációban rögzítettek) funkcionális leírásokat készítenek (melyet a Funkcionális Specifikáció dokumentumban rögzítenek), amelyekből egy végleges megoldási tervet jellemzően három-kilenc hónap alatt készítenek el, de akár több időt is igénybe vehet. Ezek a módszerek nyilvánvalóan egészen különböző megközelítések, mégis mindkettő tartalmazza az SDLC fázisokat, amelyekben egy követelmény megszületik, majd áthalad a karbantartás és támogatás végső fázisában végződő életciklus-fázisokon, amelyek után (jellemzően) az egész életciklus újrakezdődik a szoftveralkalmazás későbbi verziójához.

Előzmények és részletek

A termék életciklusa leírja az információs rendszerek felépítését nagyon tudatosan, strukturáltan és módszeresen, megismételve a termék élettartamának minden egyes szakaszát. A rendszerfejlesztési életciklus Elliott & Strachan & Radford (2004) szerint "Az 1960-as évektől vált fontossá a nagyszabású funkcionális üzleti tervek modellje. Az információs rendszerekkel kapcsolatos tevékenységek a nehéz adatfeldolgozás és a számot törő rutinok körül forogtak".

Számos rendszerfejlesztési keretrendszer részben az SDLC-n alapult, mint például az Egyesült Királyság kormányzati kereskedelmi hivatala számára az 1980-as években készített strukturált rendszerek elemzési és tervezési módszere (SSADM). Azóta, Elliott szerint (2004) "A hagyományos életciklus megközelítések helyett egyre inkább alternatív megközelítéseket használnak, amelyek megpróbálják leküzdeni a hagyományos SDCL-ben rejlő hiányosságokat."

Fázisok

A rendszerfejlesztési életciklus-keretrendszer az, ami tevékenységek sorozatát biztosítja a rendszertervezők és -fejlesztők számára. Ez egy sor olyan lépésből vagy fázisból álló folyamat, amelyben az SDLC minden egyes fázisa az előző eredményeit használja fel.

Az SDLC olyan fontos fázisokat tart be, amelyek elengedhetetlenek a fejlesztők számára – például a tervezés, az elemzés, a tervezés és a megvalósítás –, melyet az alábbi szakasz ismertet. Ez magában foglalja a jelenleg használt rendszer értékelését, az információgyűjtést, a megvalósíthatósági tanulmányokat és a jóváhagyás kérését. Számos SDLC modell jött létre, beleértve a vízesés, szökőkút, spirál stb. Ezek közül a legrégebbi és a legismertebb a vízesés modell, egy olyan szakaszsorozat, amelyben az egyes szakaszok kimenete lesz a következő bemenet. Ezeket a szakaszokat különböző módokon lehet jellemezni és felosztani, többek között a következőkre:

Előzetes elemzés: Kezdje az előzetes elemzéssel, javasoljon alternatív megoldásokat, írja le a költségeket és hasznokat, és nyújtson be ajánlásokat.

Végezze el az előzetes elemzést: Fedezze fel a szervezet céljait, valamint a vizsgált probléma jellegét és hatókörét. Még akkor is, ha a probléma csak a szervezet egy kis szegmensére vonatkozik, megtudja, mik a szervezet céljai. Ha kész, nézd meg, hogyan illeszkedik a vizsgált problémára.
Alternatív megoldások felajánlása: A szervezet célkitűzéseinek és konkrét problémáinak alapos vizsgálata után számos megoldást fedezhettek fel. A pótjavaslatok azonban továbbra is származhatnak az alkalmazottak, ügyfelek, beszállítók és/vagy tanácsadók meghallgatásából. Betekintést nyerhetünk a versenytársak kutatásába is.
Költség-haszon elemzés: Elemezze és írja le a javasolt változtatások végrehajtásának költségeit és előnyeit. A végső döntést arról, hogy a rendszert úgy hagyják-e, javítsák-e, vagy új rendszert fejlesszenek ki, azt az előzetes elemzési adatok segítségével fogják véglegesíteni.

Rendszerelemzés, követelmények meghatározása: Projektcélok definiálása a tervezett alkalmazás meghatározott függvényeiben és műveleteiben. Ez magába foglalja a tények összegyűjtésének és értelmezésének folyamatát, a problémák diagnosztizálását és a rendszer javításának ajánlását. A projekt céljait tovább segíti a végfelhasználói információs igények elemzése, valamint az e követelmények esetleges következetlenségeinek és hiányosságainak megszüntetése.

A fejlesztő által követendő lépések sorozata a következő:

Tények gyűjtése: A végfelhasználói követelmények beszerzése dokumentációval, ügyfélinterjúkkal, megfigyeléssel és kérdőívekkel.
A meglévő rendszer vizsgálata: Azonosítsa a jelenlegi rendszer előnyeit és hátrányait, hogy az előnyöket továbbvigye és elkerülje a régi rendszerben lévő hátrányokat.
A javasolt rendszer elemzése: Megoldásokat találhat a második lépésben leírt hiányosságokra, és a specifikációkat a konkrét felhasználói javaslatok alkalmazásával kell elkészíteni.

Rendszerek tervezése: Ebben a lépésben a kívánt funkciókat és műveleteket részletesen ismertetjük, beleértve a képernyő elrendezéseket, az üzleti szabályokat, a folyamatábrákat, a pszeudokódot és az egyéb dokumentációt.
Fejlesztés: Itt van megírva az igazi kód.

Integráció és tesztelés

Az összes modul egy speciális tesztelési környezetbe kerül, majd ellenőrzik a hibákat, üzemzavarokat és az átláthatóságot.

Elfogadás, telepítés: Ez a kezdeti fejlesztés végső szakasza, ahol a szoftver éles környezetbe kerül, és tényleges üzletet futtat.
Karbantartás: Az SDLC karbantartási szakaszában a rendszert értékelik, annak biztosítása érdekében, hogy az ne váljon elavulttá. Ez az a hely, ahol a kezdeti szoftvereken módosítások történnek.
Értékelés: Egyes vállalatok ezt nem tekintik az SDLC hivatalos szakaszának, míg mások úgy vélik, hogy ez a karbantartási szakasz kiterjesztése, és egyes körökben a végrehajtás utáni felülvizsgálatnak tekintik. Ez az, ahol értékelik a rendszert, valamint az egész fejlesztési folyamatot. A megválaszolandó kérdések közé tartozik, hogy az újonnan bevezetett rendszer megfelel-e a kezdeti üzleti követelményeknek és célkitűzéseknek: a rendszer megbízható és hibatűrő, a jóváhagyott funkcionális követelményeknek megfelelően működik. A kiadott szoftver értékelése mellett fontos a fejlesztési folyamat hatékonyságának felmérése. Ha vannak olyan aspektusai a teljes folyamatnak (vagy bizonyos szakaszoknak), ahol a vezetés nem elégedett, akkor itt az idő, hogy javítsanak rajta.
Ártalmatlanítás: Ebben a fázisban terveket dolgoznak ki a rendszerinformációk, hardverek és szoftverek használatának megszüntetésére és az új rendszerre való áttérésre. A cél itt az, hogy a hardver és a szoftver megfelelően mozgassa, archíválja, dobja ki, vagy semmisítse meg az információkat, hogy a csere, olyan módon menjen végbe, amely megakadályozza annak lehetőségét, hogy jogosulatlan emberek számára nyilvánosságra hozzon adatokat. Az ártalmatlanítási tevékenységek biztosítják az új rendszerre való megfelelő átállást. Különös hangsúlyt kap az előző rendszer által feldolgozott adatok megfelelő megőrzése és archiválása. Mindezt a szervezet biztonsági követelményeinek megfelelően kell elvégezni.

A következő ábrán látható, hogy a rendszerfejlesztési életciklusok ezen szakaszai tíz lépésből állnak, a definíciótól az informatikai munkatermékek létrehozásáig és módosításáig:

Természetesen nem minden projektnek kell követnie az ábrán látható mintát. A fázisok azonban kölcsönösen függenek egymástól. A projekt méretétől és összetettségétől függően a fázisok kombinálhatók vagy átfedésben lehetnek.

Rendszervizsgálat

Először kivizsgálják az informatikai rendszerre vonatkozó javaslatot. E lépés során vegye figyelembe az összes érintett aktuális prioritást és azok kezelésének módját. Mielőtt bármilyen rendszertervezésbe fogunk, megvalósíthatósági tanulmányt kell végezni annak megállapítására, hogy egy új vagy továbbfejlesztett rendszer létrehozása életképes megoldás lesz-e. Ez segít meghatározni a költségeket, előnyöket, erőforrás-igényeket és a befejezéséhez szükséges konkrét felhasználói igényeket. A fejlesztési folyamat csak akkor folytatódhat, ha a vezetőség jóváhagyja a megvalósíthatósági tanulmány ajánlásait.

A megvalósíthatósági tanulmány különböző összetevői a következők:

Működési megvalósíthatóság
Pénzügyi megvalósíthatóság
Műszaki megvalósíthatóság
Emberi tényezők megvalósíthatósága
Jogi/politikai megvalósíthatóság

Elemzés

Az elemzés célja, hogy meghatározza hol van a probléma, annak érdekében, hogy kijavítsa a rendszert. Ebbe a lépésbe tartozik, a rendszer darabokra bontása, hogy elemezhessük a helyzetet, a projekt céljait, és eldönthessük, mit kell létre hozni, ebbe megpróbáljuk a felhasználókat is bele vonni, hogy a pontos elvárásaikat megfogalmazhassák.

Tervezés

A rendszerek tervezésénél a tervezési funkciók és műveletek részletes leírása történik, beleértve a képernyő elrendezéseket, az üzleti szabályokat, a folyamatábrákat és egyéb dokumentációkat. Ennek a szakasznak a kimenete az új rendszert modulok vagy alrendszerek gyűjteményeként írja le.

A tervezési szakasz a jóváhagyott követelmények dokumentumában meghatározott követelményeket veszi kezdeti bemenetként. Minden követelmény esetében egy vagy több tervezési elem fog elkészülni, interjúk, workshopok és/vagy prototípus-próbák tesztelésének eredményeként.

A tervezési elemek részletesen ismertetik a kívánt rendszerjellemzőket, és általában funkcionális hierarchia diagramokat, képernyő elrendezési diagramokat, üzleti szabályok tábláit, üzleti folyamatábrákat, pszeudokódot és teljes entitáskapcsolati diagramot tartalmaznak teljes adatszótárral. Ezek a tervezési elemek a rendszer kellő részletességgel történő leírására szolgálnak, így a képzett fejlesztők és mérnökök minimális további beviteli tervezéssel fejleszthetik és szállíthatják a rendszert.

Környezetek

A környezetek ellenőrzött területek, ahol a rendszerfejlesztők az SDLC-n áthaladó rendszereket hozhatják létre, terjeszthetik, telepíthetik, konfigurálhatják, tesztelhetik és végrehajthatják. Minden környezet az SDLC különböző területeihez igazodik, és célja, hogy meghatározott célokat szolgáljon. Ilyen környezetek például a következők:

olyan fejlesztői környezet, ahol a fejlesztők egymástól függetlenül dolgozhatnak, mielőtt megpróbálnák egyesíteni munkájukat mások munkájával
közös építési környezet, ahol egyesített munka épülhet, együttesen, kombinált rendszerként
rendszerintegrációs vizsgálati környezet,ahol a rendszer integrációs pontjainak más felfelé vagy lefelé irányuló rendszerekre vonatkozó alapvető tesztelése végezhető el
felhasználói elfogadási tesztelési környezet, ahol az üzleti szereplők tesztelhetik eredeti üzleti követelményeiket
termelési környezet,ahol a rendszereket végül a tervezett végfelhasználók végső használatra telepítik.

Tesztelés

A kódot különböző szinteken tesztelik a szoftvertesztelők. Leggyakoribb tesztek: egység-, rendszer- és felhasználói elfogadási tesztek. Ez egy szürke terület: annyi különböző vélemény létezik, hogy melyik szakaszában, mit kell vizsgálni, és mennyi (ha van) iteráció fordul elő. Az iteráció általában nem része a vízesés modellnek, de a hibák kijavítására és a javítások üzembe helyezés előtti érvényesítésére használt eszközök beépülnek ebbe a fázisba.

A fejlesztés alatt álló rendszer típusától függő tesztelések a következők lehetnek:

Defektes tesztelés (bennfoglalja az elbukott részeket is) – Defect testing
Path testing
Data set testing
Unit testing
System testing
Integration testing
Fekete dobozos tesztelés – Black-box testing
Fehér dobozos tesztelés – White-box testing
Regression testing
Automation testing
Felhasználói elfogadásos tesztelés – User acceptance testing
Teljesítményi tesztelés – Software performance testing

Képzés és átmenet

Miután a rendszer megfelelő teszteléssel stabilizálódott, az SDLC biztosítja, hogy a rendszer képzése megfelelően megtörtént vagy dokumentált, mielőtt a rendszert átadnánk a támogató személyzetnek és a végfelhasználóknak. A képzés általában azon személyek operatív képzésére terjed ki, akik felelősek a rendszer támogatásáért, valamint azon végfelhasználók képzésére, akik a rendszert a termelési működési környezetbe történő szállítást követően fogják használni.

A képzés sikeres befejezése után a rendszermérnökök és -fejlesztők átváltják a rendszert a végső termelési környezetbe, ahol azt a végfelhasználók kívánják használni, valamint a támogató és üzemeltetési személyzet támogatja.

Üzemeltetés és karbantartás

A rendszer kiadása tartalmazza azokat a változásokat és fejlesztéseket, amik segítik megelőzni a rendszer összeomlását, vagy végét. A rendszer karbantartása az SDLC fontos szempontja. Mivel a rendszer a végfelhasználók kezébe kerül, új változásokat kell végrehajtani. A rendszerfejlesztésnek két megközelítése van: a hagyományos megközelítés (strukturált) és az objektumorientált. Az információtervezés magában foglalja a hagyományos rendszermegközelítést, amelyet strukturált elemzési és tervezési technikának is neveznek. Az objektumorientált megközelítés az információs rendszert olyan objektumok gyűjteményeként tekinti meg, amelyek egy teljes és kész információs rendszert hoznak létre.

Kiértékelés

Az SDLC utolsó fázisa a rendszer hatékonyságának mérése és a lehetséges fejlesztések értékelése.

Rendszerelemzés és -tervezés

A rendszerelemzés és -tervezés (EV) olyan információs rendszerek (IS) kifejlesztésének folyamata, amelyek hatékonyan használják a hardvert, a szoftvert, az adatokat, a folyamatokat és az embereket a vállalat üzleti célkitűzéseinek támogatására. Ez egy új üzleti rendszer megtervezése vagy egy meglévő rendszer felváltásának folyamata, annak összetevőinek vagy moduljainak meghatározásával, hogy megfeleljen az egyedi követelményeknek. A rendszerelemzés és -tervezés metafejlesztési tevékenységnek tekinthető, amely a tér beállítását és a probléma megkötését szolgálja. Az EV-t ki lehet használni, hogy megfelelő egyensúlyt állítson fel a funkcionális és nem funkcionális elemzési területeken a konkurens magas szintű követelmények között. A rendszerelemzés és -tervezés erősen együttműködik az elosztott vállalati architektúrával, a vállalati I.T. architektúrával és az üzleti architektúrával, és nagymértékben támaszkodik olyan fogalmakra, mint a particionálás, a felületek, a személyiségek és a szerepkörök, valamint a telepítési/működési modellezés, hogy magas szintű rendszerleírást találjon. Ezt a magas szintű leírást ezután tovább bontják elemekre és modulokra, amelyeket lehet elemezni, megtervezni és megépíteni külön, hogy az integrálással elérjük az üzlet céljátt. Az SDLC és az SAD a teljes életciklusú termék- és rendszertervezés sarokkövei.

Objektumorientált elemzés

Az objektumorientált elemzés (OOA – Object-Oriented Analysis) egy feladat (más néven problémás tartomány) elemzésének folyamata egy fogalmi modell kidolgozásához, amely ezután a feladat elvégzéséhez használható. Egy tipikus OOA-modell olyan számítógépes szoftvereket írna le, amelyek az ügyfél által meghatározott követelmények teljesítésére használhatók. A problémamegoldás elemzési szakaszában a programozó fontolóra vehet egy írásos követelmény nyilatkozatot, egy hivatalos jövőkép dokumentumot, vagy interjúkat a részvényesekkel vagy más érdekelt felekkel. A megoldandó feladat több altevékenységre (vagy tartományra) osztható, amelyek mindegyike más üzleti, technológiai vagy egyéb érdeklődési területet képvisel. Minden altevékenység külön-külön lesz elemezve. A megvalósítási korlátokat (pl. egyidejűség, elosztás, perzisztencia vagy a rendszer felépítésének módját) az elemzési szakaszban nem veszik figyelembe; inkább az objektumorientált tervezés (OOD) során foglalkoznak ezekkel.

Az OOA-ból származó koncepcionális modell általában használati esetekből, egy vagy több UML-osztálydiagramból és számos kapcsolati tevékenységi diagramból áll . Ez is tartalmazhat valamilyen felhasználói felület makettet.

Az objektumorientált tervezés bemenetét az objektumorientált elemzés kimenete biztosítja. A kimeneti műterméket nem kell teljesen fejleszteni, hogy szolgáljon bemeneti objektumorientált tervezést; elemzés és tervezés párhuzamosan is előfordulhat, és a gyakorlatban az egyik tevékenység eredményei rövid visszacsatolási ciklusban táplálhatják a másikat egy iteratív folyamat során. Mindkettőt, az elemzést és a tervezést is lehet lépésenként végezni, valamint az eredményt is lehet folyamatosan fejleszteni.

Néhány tipikus (de minden típusú tervezési elemzésre jellemző) beviteli összetevő az objektumorientálthoz:

Koncepcionális modell: Koncepcionális modell az objektumorientált elemzés eredménye, rögzíti a problématartomány fogalmait. A koncepcionális modell kifejezetten úgy van kiválasztva, hogy független legyen a megvalósítás részleteitől, például az egyidejűségtől vagy az adattárolástól.
Használati eset:A használati eset olyan eseménysorozatok leírása, amelyek együttesen egy olyan rendszerhez vezetnek, amely valami hasznosat tesz. Minden használati eset egy vagy több forgatókönyvet biztosít, amelyek azt közvetítik, hogy a rendszernek hogyan kell együttműködnie a szereplőknek nevezett felhasználókkal egy adott üzleti cél vagy funkció elérése érdekében. A használati eset szereplői lehetnek végfelhasználók vagy más rendszerek. Sok esetben a használati eseteket tovább dolgozzuk ki az esetábrákba. Az esetábrák segítségével azonosíthatja az aktor (felhasználók vagy más rendszerek) és az általuk végrehajtott folyamatokat.
A rendszer szekvencia diagram: A rendszerszekvenciadiagram (SSD) egy olyan kép, amely egy használati eset adott forgatókönyve esetén megjeleníti a külső szereplők által létrehozott eseményeket, azok sorrendjét és lehetséges rendszerközi eseményeket.
Felhasználói felület dokumentációi (ha vannak): Dokumentum, amely a végtermék felhasználói felületének megjelenését mutatja és ismerteti. Ez nem kötelező, de ez segít, hogy vizualizálja a végterméket, és ezáltal segít a fejlesztőknek is.
Relációs adatmodell (ha van): Az adatmodell egy absztrakt modell, amely leírja, hogyan jelennek meg és használhatók az adatok. Ha nem használ objektumadatbázist, a relációs adatmodellt általában a tervezés előtt kell létrehozni, mivel az objektumrelációs leképezéshez választott stratégia az OO tervezési folyamat kimenete. Azonban lehetőség van a relációs adatmodell és az objektumorientált tervezési leletek párhuzamos elkészítésére.

Életciklus

Kezelés és vezérlés

Az SDLC-fázisok programozott útmutatóként szolgálnak a projekttevékenységhez, és rugalmas, de következetes módot biztosítanak a projektek projekthatókörének megfelelő mélységeibe való belátásra. Az SDLC-fázis minden célkitűzését ebben a szakaszban ismertetjük, amely tartalmazza a legfontosabb célokat, az ajánlott feladatok leírását és a hatékony irányítás kapcsolódó ellenőrzési célkitűzéseinek összefoglalását. A projektmenedzser számára rendkívül fontos, hogy a projektek végrehajtása során minden SDLC-fázisban meghatározza és nyomon kövesse az ellenőrzési célkitűzéseket. Az ellenőrzési célkitűzések segítenek a kívánt eredmény vagy cél egyértelmű megfogalmazásában, és azokat a teljes SDLC-folyamat során alkalmazni kell. Az ellenőrzési célkitűzések fő kategóriákba (tartományokba) csoportosíthatók, és az SDLC-fázisokra vonatkoznak az ábrán látható módon.

Bármely SDLC-kezdeményezés kezeléséhez és ellenőrzéséhez minden projektnek létre kell hoznia bizonyos fokú munka lebontási struktúrát (WBS) a projekt befejezéséhez szükséges munka rögzítéséhez és ütemezéséhez. A WBS-t és az összes programozott anyagot a projektjegyzetfüzet "projektleírás" részében kell tárolni. A WBS formátum többnyire a projektmenedzserre van bízva, hogy a projektmunkát legjobban leíró módon hozza létre.

Vannak olyan kulcsfontosságú területek, amelyeket a WBS-ben az SDLC-politika részeként meg kell határozni. Az alábbi ábra három olyan kulcsfontosságú területet ismertet, amelyekkel a WBS a projektmenedzser által meghatározott módon foglalkozik. Az ábra az SDLC számos fázisát mutatja, de a kapcsolódó MCD-nek van egy részhalmaza az SDLC fázisokhoz. Az Elemzés és tervezés például elsősorban az Akvizíció és megvalósítás tartomány részeként történik, a Rendszerépítés és -prototípus pedig elsősorban a szállítás és a támogatás részeként történik.

Munkabontás strukturált szervezethez

A munkalebontási struktúra (WBS) felső részében összefoglaló módon kell meghatározni a projekt főbb fázisait és mérföldköveit. Ezenkívül a felső résznek áttekintést kell nyújtania a projekt teljes hatóköréről és ütemtervéről, és a projekt jóváhagyásához vezető kezdeti projektleírási munka részét képezi. A WBS középső szakasza a hét rendszerfejlesztési életciklus-fázison alapul, amelyek útmutatóként szolgálnak a WBS-feladatok fejlesztéséhez. A WBS-elemeknek mérföldkövekből és "tevékenységekből" kell állniuk, szemben a "tevékenységekkel", és végleges időszakkal kell rendelkezniük (általában két hét vagy több). Minden feladatnak mérhető kimenettel kell rendelkeznie (e.x. dokumentum, döntés vagy elemzés). A WBS-feladatok egy vagy több tevékenységre támaszkodhatnak (pl. szoftverfejlesztés, rendszerfejlesztés), és szoros koordinációt igényelhetnek más feladatokkal, akár belső, akár külső feladatokkal. A projekt bármely olyan részének, amelynek alvállalkozói támogatásra van szüksége, rendelkeznie kell egy munkanyilatkozattal (SOW), amely tartalmazza az SDLC-szakaszok megfelelő feladatait. A munkanyilatkozat kifejlesztése nem az SDLC egy adott szakaszában történik, hanem úgy fejlesztik ki, hogy magában foglalja az SDLC-folyamatból származó munkát, amelyet külső erőforrások, például vállalkozók végezhetnek.

Alapvonalak

Az alapvonalak fontos részét képezik a rendszerfejlesztési életciklusnak. Ezeket az alapértékeket az SDLC öt fázisából négy után állapítják meg és kritikusak a modell iteratív jellege szempontjából. Minden alapvonal mérföldkőnek számít az SDLC-ben.

funkcionális kiindulási érték: a koncepcionális tervezési szakasz után jött létre.
kiosztott kiindulási érték: az előzetes tervezési szakasz után jött létre.
termékalapvonal: a részletes tervezési és fejlesztési fázis után állapítják meg.
a korszerűsített termékalapvonal: a gyártás építési szakasza után állapítható meg.

Kiegészítő módszerek

A rendszerek fejlesztésének életciklusához a következő kiegészítő szoftverfejlesztési módszerek:

A módszertani megközelítések összehasonlítása (Post, & Anderson 2006)
	SDLC	RAD	Nyílt forrás	Objektumok	JAD	Prototípus	Végfelhasználó
Ellenőrzés	Hivatalos	MIS	Gyenge	Szabályok	Közös	Felhasználó	Felhasználó
Időkeret	Hosszú	Rövid	Közepes	Bármely	Közepes	Rövid	Rövid
Felhasználó	Sok	Néhány	Néhány	Változik	Néhány	Egy vagy kettő	Egy
MIS személyzet	Sok	Néhány	Több száz	Split	Néhány	Egy vagy kettő	Nincs
Tranzakció/DSS	Tranzakció	Mind	Mind	Mind	DSS	DSS	DSS
Interface	Minimális	Minimális	Gyenge	Windows	Döntő	Döntő	Döntő
Dokumentáció és képzés	Létfontosságú	Korlátozott	Belső	Objektumban	Korlátozott	Gyenge	Nincs
Integritás és biztonság	Létfontosságú	Létfontosságú	Ismeretlen	Objektumban	Korlátozott	Gyenge	Gyenge
Újrafelhasználhatóság	Korlátozott	Néhány	Talán	Létfontosságú	Korlátozott	Gyenge	Nincs

Erősségek és gyengeségek

Kevesebb ember van a modern számítástechnikai világban, aki egy szigorú vízesés modellt használna, mint azok, akik az SDLC modern módszereit választanák rövid átgondolás után. Egyesek azzal érvelnek, hogy az SDLC már nem tartozik a modellek közé, mint az Agilis számítástechnika, de ez még mindig egy olyan kifejezés, amelyet széles körben használnak a technológiai körökben. Az SDLC gyakorlatnak előnyei vannak a rendszerek fejlesztésének hagyományos modelljeiben, amelyek jobban alkalmasak a strukturált környezetre. Az SDLC-módszertan használatának hátránya, ha iteratív fejlesztésre van szükség (azaz webfejlesztésre vagy e-kereskedelemre), ahol az érdekelteknek rendszeresen felül kell vizsgálniuk a tervezett szoftvert.

Az SDLC erősségeinek és gyengeségeinek összehasonlítása:

Az SDLC erőssége és gyengeségei
Erősségeit	Gyengeségeit
Ellenőrzés	Megnövekedett fejlesztési idő
Nagy projektek figyelése	Megnövekedett fejlesztési költségek
Részletes lépések	A rendszereket előre meg kell határozni
A költségek és a befejezési célok kiértékelése	Merevség
Dokumentáció	Nehéz megbecsülni a költségeket, a projekt túllépéseit
Jól definiált felhasználói bevitel	A felhasználói bevitel néha korlátozott
Egyszerű karbantartás	Kis párhuzamosság
Fejlesztési és tervezési szabványok	A dokumentáció és a szabványok automatizálása korlátozott
Tolerálja a változásokat a MIS a személyzet	Nem tűri a követelmények változásait
	Projektek korai változatai az eredményhez alig vagy egyáltalán nem érnek fel

Az SDLC alternatívája a gyors alkalmazásfejlesztés, amely egyesíti a prototípusokat, a közös alkalmazásfejlesztést és a CASE eszközök megvalósítását. A RAD előnyei a sebesség, a csökkentett fejlesztési költségek és a fejlesztési folyamatban a felhasználók aktív részvétele.

A rendszer életciklusa

A rendszerfejlesztés rendszeréletciklusa egy olyan rendszer vagy javasolt rendszer nézete, amely a rendszer tervezésének és fejlesztésének, gyártásának és/vagy építésének, forgalmazásának, üzemeltetésének, karbantartásának és támogatásának, a nyugdíjba vonulásnak, a megszüntetésnek és az ártalmatlanításnak a rendszertervezését, tervezését és fejlesztését, gyártását és/vagy felépítését, elosztását, karbantartását és támogatását, nyugdíjazását, fokozatos megszüntetését és ártalmatlanítását foglalja magában.

Koncepcionális tervezés

A koncepcionális tervezési szakasz az a szakasz, ahol az azonosított szükségletet megvizsgálják, meghatározzák a lehetséges megoldásokra vonatkozó követelményeket, értékelik a lehetséges megoldásokat, és kidolgoznak egy rendszerspecifikációt. A rendszerspecifikáció azokat a műszaki követelményeket képviseli, amelyek átfogó útmutatást nyújtanak a rendszer tervezéséhez. Mivel ez a dokumentum határozza meg az összes jövőbeli fejlesztést, a szakasz nem fejezhető be, amíg egy koncepcionális tervezési felülvizsgálat nem állapítja meg, hogy a rendszerspecifikáció megfelelően eleget tesz a motiváló igénynek.

A koncepcionális tervezési szakasz legfontosabb lépései a következők:

Azonosításra van szükség
Megvalósíthatósági elemzés
Rendszerkövetelmények elemzése
A rendszer specifikációja
Koncepcionális tervezési felülvizsgálat

Előzetes rendszertervezés

A rendszer életciklusának ebben a szakaszában a kívánt rendszerfunkciókat ellátó alrendszereket a rendszerspecifikációnak megfelelően tervezték és határozták meg. Meghatározzák az alrendszerek közötti kapcsolódási pontokat, valamint az általános vizsgálati és értékelési követelményeket. Ennek a szakasznak a végén olyan fejlesztési specifikáció készül, amely elegendő a részletes tervezéshez és fejlesztéshez.

Az előzetes tervezési szakasz legfontosabb lépései a következők:

Funkcionális elemzés
Követelmények felosztása
Részletes kompromisszumos tanulmányok
A rendszeropciók szintézise
A mérnöki modellek előzetes tervezése
Fejlesztési specifikáció
Előzetes tervezési felülvizsgálat

Például, mint a Viti Bank rendszerelemzője, az Ön feladata, hogy vizsgálja meg az aktuális információs rendszert. A Viti Bank egy gyorsan növekvő bank a Fidzsi-szigeteken. A távoli vidéki területeken élő ügyfelek nehezen férnek hozzá a banki szolgáltatásokhoz. Napokba vagy akár hetekbe telik, hogy elutazzanak egy helyre, hogy hozzáférjenek a banki szolgáltatásokhoz. Azzal a vízióval, hogy megfeleljen az ügyfelek igényeinek, a bank kérte őket, hogy a szolgáltatásukkal vizsgálja meg a jelenlegi rendszert, és dolgozzon ki megoldásokat vagy ajánlásokat, hogy a jelenlegi rendszer megfeleljen az igényeknek.

Részlettervezés és fejlesztés

Ez a szakasz magában foglalja a részletes tervek kidolgozását, amelyek a kezdeti tervezési munkát a specifikációk kitöltött formájába hozzák. Ez a munka magában foglalja a rendszer és a tervezett környezet közötti kapcsolódási pontok meghatározását, valamint a rendszerek logisztikai, karbantartási és támogatási követelményeinek átfogó értékelését. A részletes tervezés és fejlesztés felelős a termék, a folyamat és az anyag specifikációinak előállításáért, és a fejlesztési specifikáció lényeges megváltoztatását eredményezheti.

A részletes tervezési és fejlesztési szakasz legfontosabb lépései a következők:

Részletes tervezés
Részletes szintézis
Mérnöki és prototípus modellek fejlesztése
A fejlesztési előírás felülvizsgálata
Termék-, folyamat- és anyagspecifikáció
Kritikus tervezési felülvizsgálat

Termelés és építés

A gyártási és/vagy kivitelezési szakaszban a terméket a termékre, a folyamatra és az anyagra vonatkozó előírásokban meghatározott követelményeknek megfelelően építik vagy szerelik össze, és az üzemi célkörnyezetben alkalmazzák és tesztelik. A rendszerértékeléseket a hiányosságok kijavítása és a rendszer folyamatos fejlesztéshez való hozzáigazítása érdekében végzik el.

A terméképítési szakasz legfontosabb lépései a következők:

Rendszerelemek gyártása és/vagy építése
Elfogadási vizsgálat
A rendszer elosztása és üzemeltetése
Működési tesztelés és értékelés
A rendszer értékelése

Kihasználtság és támogatás

A teljes körű üzembe helyezést követően a rendszer a tervezett operatív szerepkörhöz használatos, és a működési környezetében marad fenn.

A kihasználtsági és támogatási szakasz legfontosabb lépései a következők:

Rendszerműködés a felhasználói környezetben
Változáskezelés
A rendszer javítása
A rendszer értékelése

Fokozatos kivonás és ártalmatlanítás

A rendszer hatékonyságát és eredményességét folyamatosan értékelni kell annak megállapítására, hogy a termék elérte-e a maximális tényleges életciklust. A megfontolások a következők: a működési szükséglet folyamatos megléte, az üzemeltetési követelmények és a rendszerteljesítmény egyeztetése, a rendszer fokozatos megszüntetése és a karbantartás megvalósíthatósága, valamint az alternatív rendszerek rendelkezésre állása.

Lásd még

További információk

A Wikimédia Commons tartalmaz Rendszerfejlesztési életciklus témájú médiaállományokat.

The Agile System Development Lifecycle
Pension Benefit Guaranty Corporation – Information Technology Solutions Lifecycle Methodology
FSA Life Cycle Framework
HHS Enterprise Performance Life Cycle Framework Archiválva 2013. június 7-i dátummal a Wayback Machine-ben
The Open Systems Development Life Cycle Archiválva 2010. július 18-i dátummal a Wayback Machine-ben
System Development Life Cycle Evolution Modeling
Zero Deviation Life Cycle
Integrated Defense AT&L Life Cycle Management Chart, the U.S. DoD form of this concept.