SDLC útmutató - Szoftverfejlesztés életciklusának fázisai és módszertanai

Amikor majdnem négy évvel ezelőtt úgy döntöttem, hogy megtanítom magam a kódolásra, még soha nem hallottam, nem is gondoltam a szoftverfejlesztés életciklusáról.

Vadonatúj fejlesztőként azon technológiák elsajátítására összpontosítottam, amelyek elősegítik az áhított első fejlesztői munkát, és nem az egyes csapatok működésének árnyalatait.

Amikor megtudtam róluk, azt gondoltam, hogy haszontalanok lennének számomra, mert webfejlesztőnek, nem pedig szoftverfejlesztőnek tartottam magam.

Azóta megtudtam, hogy ez nem állhat távolabb az igazságtól, és ezek az elvek / gyakorlatok nagy szerepet játszanak a mindennapi tevékenységeim során (függetlenül attól, hogy rájövök-e vagy sem).

Elég szerencsés vagyok látni, hogy az általam írt kód, az általam felépített szolgáltatások és a véletlenül bevezetett hibák (több, mint amennyit beismerek) befolyásolják a végfelhasználót és tapasztalataikat. Ez a tapasztalat segített abban, hogy gondolkodjak a termékek építésének folyamatáról és a felhasználók problémáinak megoldásáról.

Volt időm gondolkodni azon különbségeken (és hasonlóságokon), amelyeket ezek a megközelítések kínálnak. Alapvetően mindegyik arra összpontosít, hogy a lehető leghatékonyabban és a lehető legköltséghatékonyabban szállítson kiváló minőségű szoftvereket.

Szakmailag csak egy vagy két ilyen módszert alkalmaztam. De akkor is találok értéket, ha legalább mindegyiket megértem.

Mindezek a módszertanok ehhez a diagramhoz hasonló fázisok sorozatát követik:

Tehát itt vannak a szoftverfejlesztés életciklusának módszerei (nem külön sorrendben):

  • Sovány
  • Agilis
  • Vízesés
  • Ismétlődő
  • Spirál
  • Dev Ops

Bemutassuk az egyes módszerek különbségeit és hasonlóságait.

Sovány

A Lean módszertan nagyban támaszkodik és hét alapelvből áll.

Nincsenek külön sorrendben:

  1. Szüntesse meg a hulladékot
  2. A tanulás erősítése
  3. Döntsön a lehető legkésőbb
  4. A lehető leggyorsabban szállítson
  5. Felhatalmazza a csapatot
  6. Építsd az integritást
  7. Lásd / Optimalizálja az egészet

Minden elvnek sajátos célja van, előnyökkel, amelyek egymást kiegészítik.

A pazarlás (extra funkciók, hiányos munka, vezetői megbízások stb.) Kiküszöbölése nagyobb értéket teremt az ügyfél számára, ami viszont növeli az elégedettséget.

A tanulás kibővítése lehetővé teszi a csapatok számára, hogy újrabefektessék termékeiket az ügyfelekhez.

A lehető legkésőbbi döntés minden fontos döntésre utal, opcióalapú vagy meghatározott alapú megközelítést adva a csapatoknak. Ez lehetővé teszi a csapatok számára, hogy vélemények helyett tényeket gyűjtsenek össze, hogy elősegítsék a döntések befolyásolását.

A lehető leggyorsabb kézbesítés nem magától értetődő - a lehető leggyorsabban készítse el a terméket, hogy eljuttassa az ügyfelekhez értékelésre / ismétlésre.

Egy tipikus forgatókönyv szerint a menedzserek megbízásokat osztanak ki / dolgoznak a fejlesztőknek. A Lean módszertanban a fejlesztők "megtanítják" a vezetőket arra, hogyan kell meghallgatni az "árokban lévő embereket", befolyásolva ezzel a menedzsment döntéseit / döntéseit.

Ez segít csapatok úgy érzi, több felhatalmazott beszélni mintegy ides és megoldások.

Az integritás kivétel helyett szabállyá tétele azt jelenti, hogy az ügyfél bízik az épülő rendszerben. Az ügyfél tudja, hogy a rendszert úgy építik, hogy ellenálljon a megfelelő növekedésnek és szükség esetén a "nyújtásnak".

Szeretem ugyanúgy gondolkodni az integritásról, mint egy széken ülni. Amikor leülsz a székre, azt hiszed, hogy a legjobb anyagból készült, amely fel fog tartani minden alkalommal, amikor a szék életéig ülsz benne. Az ügyfélnek ugyanolyan bizalommal kell rendelkeznie az épülő termék iránt.

Végül az egész látása és optimalizálása az épülő rendszer egészére vonatkozik. Az egész optimalizálásával a szoftvereket nem sok összetevő összegeként tekintjük, hanem egy nagy egységként, amelyet a hatékonyságra optimalizáltunk.

Ez azt jelenti, hogy a fejlesztés során a terméket kezelhető darabokra bontják, és hogy a nem szándékos hibákat nemcsak felfedezik, hanem gyorsan megoldják.

Agilis

Ez a "kudarc" megközelítés a szoftverek építéséhez.

Hangsúlyt helyez a kisméretű, növekményes kibocsátásokra a folyamatban lévő kibocsátási ciklusokkal. Minden egyes iterációval a csapatok arra törekszenek, hogy azonosítsák és kezeljék az apró kérdéseket, mielőtt nagy problémákká válnának.

Ez azt is jelenti, hogy a csapatoknak be kell vonniuk az érdekelt feleket (olyan személyeket / szervezeteket, akiket a kódex végső soron érinthet, például a vezetőket, a műszaki vezetőket, a műszaki vezetőket és az ügyfeleket) visszajelzésük megszerzése érdekében.

Ha szabadúszó vagy, az érdekelt fél (ek) az ügyfelek lennének - végső soron a továbblépés előtt meg kell győződnöd az elégedettségükről a munkával.

Az Agile technikailag a Lean módszertanának elágazása, néhány figyelemre méltó különbséggel - főként kezdettől fogva az ügyfél-elégedettséget helyezi előtérbe, és lehetővé teszi a csapatok számára, hogy gyorsan reagáljanak az ügyfelek visszajelzéseire.

Bár ez a cikk hatáskörén kívül esik, van még egy összetettebb keretrendszer az Agile-n belül, amelyet SCRUM-nak hívnak. Ezt a módszertant nagy, rendkívül összetett projekteknél alkalmazzák, sőt a szoftverfejlesztésen kívül is alkalmazzák.

Vízesés

A vízesés módszertana a legtöbb szerint a legrégebbi a listán. Soha nem volt célja a szoftverfejlesztés modellje, és az építőiparban és a gyártásban kezdte meg működését.

Ez a megközelítés egyszerű a felépítésében - fejezze be a fázis minden részét, mielőtt továbblépne a következő szakaszba, és nagyobb lendülettel építkezzen a projekt befejezése felé, amint a szakaszok befejeződnek. Minden szakasz kezdete (az első kivételével) és befejezése az előző szakasz teljesítésétől / információátadásától függ.

A vízesés megközelítésnél minden szakasznak megvan a maga merev projekt terve, amely befejeződik a korábban befejezett munkák tesztelésével. Meg kell jegyezni, hogy ez a megközelítés nem ajánlott nagyobb / hosszabb ideig tartó projekteknél a fent említett merevség miatt.

Gondoljon ennek a módszertannak a genezisére, és jobban megérti. Az építőipar / gyártás világából származik, ahol általában egy-egy fázist kell elvégezni. A ház építése során nem szabad elkezdeni betenni a vízvezetéket, mielőtt a keret fel lett téve.

A szoftverfejlesztés általában nem így működik. Mint mindannyian tudjuk, néha szükségessé válik egy olyan szakasz áttekintése, amelyről korábban azt hitték, hogy befejeződött.

Ismétlődő

Ezt "ismétlődő megközelítésnek" vagy "tegyük jobbá a következő körkörössé" megközelítésnek nevezik, mivel az egyes ciklus-iterációk során a termék fejlesztésének különböző lehetőségei vannak.

Elfogult vagyok (ahogy mindannyian vagyunk: D), de ez a kedvenc életciklusom a fejlődéshez. Úgy gondolom, hogy a jelenlegi helyzetem szempontjából a legjobban működik mind szabadúszó, mind pedig karrierem terén, mert ez lehetővé teszi számomra, hogy folyamatosan "haladjak, miközben javítok a dolgokon".

Az iteratív megközelítéssel a csapatok megvalósítanak egy megoldást, tesztelik azt, értékelik annak hatékonyságát / áteresztőképességét, majd meghatározzák a további fejlesztendő területeket. Ez a fejlesztési folyamat minden ciklusára (iterációjára) megtörténik.

Minden kiadott verzióval újabb ismétlés következik, amíg a végtermék elkészül és készen áll a felhasználók számára történő közzétételre.

Az iteratív megközelítés egyik nagyszerű tulajdonsága, hogy Ön és csapata a fejlesztés elején megkapja a szoftver működő verzióját. Ez különösen hasznos lehet az érdekelt felek számára, hogy felmérjék válaszukat / visszajelzésüket.

Ennek a megközelítésnek az egyik legnagyobb hátránya, hogy nagyon gyorsan nagy mennyiségű forrást tud felemészteni. Képzelje el az összes embert, órákat, hibajavításokat és béreket, amelyek bekerülnek a fejlesztési ciklus minden egyes iterációjába, és jó képet kap az erőforrások felhasználásáról.

Ezen a megközelítésen belül a Rational Software Corporation (az IBM által megvásárolt) által kidolgozott alapelvek egy Rational Unified Process (RUP) elnevezésű részei, amelyek 4 fázisból állnak:

  • Kezdet
  • Kidolgozás
  • Építkezés
  • Átmenet (termékkiadás)

Ez az elvrendszer rugalmasnak és az azt használó minden csapat igényeihez igazodik.

Spirál

A spirál módszertan valószínűleg a legrugalmasabb a hat közül. Ez egy olyan módszer, amely a kockázatokra épül - azonosítja és negálja azokat. A kockázat (azonosítás és idegenkedés) vezérli a modell minden döntését. Négy alfázisra tagolódik:

  • Tervezés (célok)
  • Kockázatelemzés (azonosítsa a lehetséges akadályokat)
  • Fejlesztés és tesztelés (jelenlegi és következő verzió)
  • Értékelés (az aktuális szakasz és a következő szakasz tervének áttekintése)

Az egyes fázisok minden iterációja a következő fázis tervezésével kezdődik. Így azonosítják a lehetséges kockázatokat, még mielőtt azok szembe kerülnének. Ez cselekvési tervet is lehetővé tesz, amikor az említett kockázatok felmerülnek.

A fázisok során a csapatok ezen a területen is dolgoznak ezen kockázatok és a spirális fejlődés jövőbeli ismétléseire gyakorolt ​​hatásuk csökkentésén.

Amint a fejlesztési folyamat folytatódik, mind a négy alfázis spirális módon megismétlődik. Ez lehetővé teszi az egyes alfázisok többszörös finomítását a befejezésig.

Dev Ops

Ha gyors keresést hajt végre, akkor nem lesz hiány információ erről a fejlesztési életciklus-módszerről. Az új gyerek a blokkban, amely a szoftverfejlesztő és az informatikai műveleti csapatokat ugyanabba a körbe hozza.

Ezek a csapatok együtt dolgoznak annak érdekében, hogy apró, de hatásos frissítéseket nyújtsanak a gyakori ütemben érkező termékekhez. Ez viszont folyamatos visszacsatolási és fejlesztési kört hoz létre, amely hajtja a fejlesztést.

Ez a bizonyos módszertan ismert a fejlesztés manuális részeinek automatizálására is (gondolja a telepítést).

Ennek a módszertannak az az általános célja, mint a legtöbb más, a fejlesztés életciklusának lerövidítése és minőségi termékek biztosítása.

Ennek a módszertannak az egyik hátránya a szervezeten belüli jelentős gondolkodásmód és kultúraváltozás. Azoknak a csapatoknak, amelyek sok dolgot megszokhattak, csak egy vagy kettőre szűkítik a feladataikat.

Például egy általános célú fejlesztő azt tapasztalhatja, hogy most csak a tesztelési vagy a végfelhasználói élményrész feladata.

Az egészet hazahozni

Remélem, most meglátja e módszerek fontosságát és előnyeit. Ezek mindegyikének megvannak a maga erősségei és gyengeségei.

A legalapvetőbb szinten iránymutatások és alapelvek, amelyek magas színvonalú, hatékony munkát kívánnak biztosítani az érdekelt felek számára.

Amikor először kezdtem el kódolni, nem volt mentorom. A tanultak megosztásával remélem, hogy segíthetek azoknak, akik megtanulják a kódolást, amikor és ahol tudnak.

Minél több információt és tapasztalatot szeretnék megosztani más fejlesztőkkel. Remélem, ha ez a cikk segít, még ha kis mértékben is, ha kódolni tanítja magát, vagy gyakorlott fejlesztő vagy, akkor is.

Nézze meg a blogomat, ahol gyakran teszek közzé cikkeket a webfejlesztésről.

Amíg ott vagy, miért nem iratkozol fel a hírlevelemre? Ezt megteheti a fő blogoldal jobb felső sarkában. Szeretnék időnként érdekes cikkeket (az enyémet és másokat), erőforrásokat és eszközöket küldeni a fejlesztőknek.

Ha kérdésed lenne ezzel a cikkel kapcsolatban, vagy csak általánosságban a DM-jeim vannak nyitva - jöjj el köszönni a Twitteren vagy bármely más közösségi médiafiókomon, amelyet a hírlevél alatt találsz, iratkozz fel a főoldalra vagy az itt található profilomra :)

Félelmetes napot és boldog kódolást kívánunk, barátom!