From Wikipedia, the free encyclopedia
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.
 |
Ez a szócikk nem tünteti fel a független forrásokat, amelyeket felhasználtak a készítése során. Emiatt nem tudjuk közvetlenül ellenőrizni, hogy a szócikkben szereplő állítások helytállóak-e. Segíts megbízható forrásokat találni az állításokhoz! Lásd még: A Wikipédia nem az első közlés helye. |
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.
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."
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:
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.
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.
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:
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.
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.
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:
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:
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.
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.
Az SDLC utolsó fázisa a rendszer hatékonyságának mérése és a lehetséges fejlesztések értékelése.
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.
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:
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.
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.
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.
A rendszerek fejlesztésének életciklusához a következő kiegészítő szoftverfejlesztési módszerek:
| 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 |
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:
| 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 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.
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:
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:
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.
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:
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:
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:
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.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
