Erinevus SDLC ja STLC vahel
Vajadus suurendab huvi ja muudab selle protsessi käivitamise ainsaks põhjuseks. Hiljem ajab see huvi seotud ressursid, sidusrühmad, kliendid, tegevjuhi, juhid ja arendusmeeskonnad eduka projekti (siin meie puhul tarkvaraarendus) sulgemise taha. Nende inimeste käitumise ainus eesmärk pole mitte ainult raha (intressid), vaid ka aeg ja brändi väärtus (see on veelgi olulisem).
Ja siin tuleb pildile artikli teema, jah SDLC vs STLC. Mõlemad SDLC ja STLC on mingil määral omavahel seotud või võib öelda, et üks on teiste eelkäija. Põhjus on lihtne, kui midagi arendatakse teenindamiseks (kliendid vajavad), siis tuleb seda enne juurutamist testida. See on aastakümnete pikkused tööstusstandardid ja vastutus, kuna klient on pärast seda investeerinud tohutu summa raha.
See oli sündmuskoha taga olev lugu ja viib meid artikli põhiosasse - SDLC vs STLC. Vaatame üksikasjalikult, mis need SDLC vs STLC täpselt on. Milline on toimingute jada iga all? Mis vahe on SDLC ja STLC vahel? Milliseid tegevusi on vaja edukaks lõppemiseks?
SDLC tähendab tarkvara arendamise elutsüklit
ELUKESKLIK tähendab rea muutusi elus. Kas elav, elutu või protsess, millel on mõned sammud või toimingute jada. Need järjestused on omamoodi märk sellest, et sellel on kindel algus- ja lõpp-punkt. Vastupidi, võib öelda, et antud protsessis on mingi alaprotsess. See on selline elutsükkel. Arvestades, milline elutsükkel tegelikult paneb meid arutelus tarkvara arendamise suunas edasi liikuma. Niisiis, SDLC tähendab s “ tarkvara arendamise protsessi elutsüklit” .
Arendusmudelite osas pole määratletud reegleid, mis pooldaksid üksteist või konkreetset mudelit oleks hea kasutada kui teisi (paindlik on erand). Vaatame mõnda mudelit -
- Waterfall Model - kõige vanem
- V- mudel
- Spiraalmudel
- Iteratiivne
- Agiilne - uusim ja kõige sobivam igat tüüpi projekti jaoks
Märkus. Pean ütlema, et Agile scrum-mudeleid on hea kasutada, kuid IT-valdkonnas saab meeskond eelistada mõnda neist mudelitest. Nt Kui nõue on selge ja kui soovite hilisemas etapis mitte muutuda, läheb meeskond kindlasti koos Waterfalliga ja mitte Agilega.
SDLC arutelu etapid
- Planeerimine
- Süsteemianalüüs ja nõuded
- Kujundus
- Kodeerimine või arendamine
- Integreerimine ja testimine
- Kasutamine ja hooldus
Ülaltoodud protsessi võib loetleda ka allpool -
- PLANEERIMINE - Kõigepealt enne mis tahes asitõendite ilmumist on selle taga alati plaan. Planeerimine tuleb enne paberimajanduse algust. Selles etapis vaadeldakse projektide vaatenurgast ainult kõrgetasemelisi üksikasju. Selle etapi taga on spetsiaalne rühmitus liikmeid. Kaalutakse kõiki projektidega seotud eeliseid ja miinuseid ning kaalutakse ka seda, kuidas investeeringutasuvust maksimeerida ja kuidas seda teha. Projekti õnnestumise takistuste ületamiseks on vaja palju ümbertegemist ja ülevaatamist. Lõpptulemus on enne idee elluviimist, kuid sellel peaks olema konkreetseid põhjuseid, miks seda ellu viia ja edu saavutada. Planeerimine sõltub jällegi tulemuse laadist. Kui ehitatakse uut tarkvara, on planeerimine erinev, kuna turu-uuring on selle jaoks väga oluline, kuid kui sama tarkvara uuendatakse mõne aasta pärast, siis sel juhul turu-uuringut ei tehta (kuna tarkvara on edu ja seetõttu on vaja tarkvarafunktsioonide värskenduste loomist).
- ANALÜÜS - Kui planeerimisosa on tehtud, tuleb analüüs, kus pühendunud meeskonnad teevad enne konkreetse lahenduse leidmist mitu ülesannet. Siin tehakse projekti teostatavusuuring, hinnangulised tööd, kuluarvestus, vajaduste väljaselgitamine ja ajakava koostamine. Kavatsus on lõplik kontroll teha enne töö algust. Kui seal on puudusi, tuleb need kõrvaldada arendusmeeskonna ja sidusrühmadega suheldes. Uurige plusse ja miinuseid.
- KUJUNDAMINE - Nüüd on nõue selge ja meeskond soovib enne tööle asumist mingit viidet, disaineritel on ülioluline roll. Selles etapis on kavandatud, mida tarkvara töötab (tark funktsionaalsus), kui palju ekraane igas jaotises on, kasutaja interaktiivsus ja iga detail. Oletame, et klient palus lennupiletite broneerimiseks mobiilset tarkvara ja nõue on selge, et disainerid kavandavad ekraanid, et katta funktsioonid, mida see tarkvara töötleb. Projekteerijad esitavad kujunduse, tööplaanid, protsessidiagrammid, pseudokoodid ja mitmed muud laadi kujundusdokumentatsioonid. Vastutavad isikud valivad parima, kellega kaasa minna.
- KODEERIMINE - praeguses etapis on enamik olulisemaid otsuseid juba otsustatud. Selle etapi eesmärk on reprodutseerida disainilahendused töötavaks tarkvaraosaks. Siin mängivad olulist rolli arendajad ja tehakse pingutusi korduvkasutatavate koodide tootmiseks. Pööratakse tähelepanu paljudele raamistikuga seotud aruteludele ja töötava tarkvara loomiseks sobivaimatele meetoditele. Kaasatud on programmeerimisriistu, mida arendajate meeskond kasutab - Kompilaator, Silur, Tõlk. Tahaksin oma lugejate tähelepanu juhtida sellele, et tervikliku töötava tarkvara arendamine pole lihtne ega ka väike. Suur tükk tööd on olemas, nii et arendusmeeskond jaotab need väiksemateks väljunditeks ja seab need tähtsuse järjekorda vastavalt vajadusele või kiireloomulisusele (saab hinnata ka selle põhjal, kui oluline on funktsionaalsus, st kui kõrgele konkreetsele funktsionaalsusele on antud hinnang). Pidage meeles, et see on arengutsükli pikim etapp.
- KATSE - selles etapis jõuab STLC. See etapp hõlmab väljatöötatud töötava tarkvara testimist enne selle edastamist klientidele või lõppkasutajatele. Testijad viivad läbi mitut tüüpi testimetoodikat, et teada saada tarkvara võimalikud puudused.
- HOOLDUS - see on omamoodi müügijärgne teenindus. Nagu viis, kuidas me ostame ükskõik millist jalgratast või autot, ja aasta pärast, kui on mõni probleem, mis takistab korralikult töötamist. Sedasorti probleemid tekivad ikka ja jälle. Siin on lahendatud kõik vead, mis kliendi tarkvara kasutamisel tekivad, tulevikus vajalik täiendamine või vajadusel täiendused.
STLC tähendab TARKVARA ELUKOHA TESTIMIST
Faasid STLC-s -
- Nõuete analüüs
- Testi planeerimine
- Testjuhtumi areng
- Keskkonna seadistamine
- Testi täitmine
- Testtsükli sulgemine
- NÕUETE ANALÜÜS - STLC-protsessi esimene samm. See on osa kogu protsessist, kus kvaliteedikontrolli meeskonnad õpivad tundma nõudeid (tähendab, mida testida) ja kontrollitavaid nõudeid. Nõude paremaks mõistmiseks saab testija klientidega ühendust võtta (kuid seda juhtub harva, ainult siis, kui on vaja testimist, mitte arendamist). See on omamoodi diagramm, mis järgnes selles STLC faasis.
| Sisenemise kriteeriumid | Tegevused läbi viidud | Saavutused |
| Täpne vajadus koos täieliku kirjeldusega, et määratleda järgitav testimisprotseduur. | Testimise liigid on loetletud selles jaotises | Saavutatud tulemused on loetletud selles jaotises |
- KATSEplaneerimine - kõige kriitilisem etapp STLC-s. Siin arvutatakse kõik hinnangud ja aeg enne testimise tegelikku algust. Selle tulemusel kontrollitakse plaanide või strateegiate dokumente. Kui see etapp on lõpule viidud, võib kvaliteedikontrolli meeskond alustada proovijuhtimise arendamisega. Sama diagrammi, mis on joonistatud ülemises faasis, kasutatakse uuesti muudatustega.
- TESTI ARENG - testijuhtumite tegelik arendamine toimib pärast testi kavandamisetapi lõppu. Siin testitav meeskonnatöö testjuhtudel. Kaasatud on ja dokumenteeritakse mitte ainult testijuhtumid, vaid täielik aruanne, mis sisaldab testi andmeid. Kui need on lõpule viidud, saavad vastastikku liikmed või kvaliteedikontrolli juhid ristkontrolli. Siin valmistatakse ka RTM (nõude jälgitavuse maatriks). Need dokumendid jälgivad nõuet mõlemal viisil (tähendab edasi ja tagasi).
- KESKKONNA SEADISTAMINE - Üldiselt seda ei kasutata, kuna keskkond on juba arendusetapis otsustatud (SDLC). Üldiselt keskkonnas muutusi ei toimu.
- KATSE TÄITMINE - siin viiakse testjuhtumid läbi esialgselt koostatud testimiskavade alusel. Kui juhtumid on korras, märgistatakse need tähisega PASS, muidu FAIL. Selles etapis koostatakse täielik vigade loend ja need edastatakse arendusmeeskonnale enne tarkvara lõplikku väljaandmist parandamiseks.
- TESTSÜKLI SULGEMINE - Arutelu, kus meeskond otsustab testi perspektiivist lähtudes, mis läks õigesti ja valesti. Sellel kohtumisel arutatakse asju, mida saaks tulevikus paremaks muuta ja mis säästaks aega ja vaeva õiges suunas. Need on arengu seisukohast kasulikud.
SDLC ja STLC (Infographics) võrdlus ühest otsast teise
Allpool on 9 peamist erinevust SDLC ja STLC vahel 
Peamised erinevused SDLC ja STLC vahel
Nii SDLC kui STLC on turul populaarsed valikud; arutagem mõnda peamist erinevust SDLC ja STLC vahel:
- SDLC on arendusmetoodika, samas kui STLC on testimismetoodika
- SDLC moodustamiseks ühendatakse mitu erinevat faasi, samal ajal kui mitu katsefaasi või tava ühendatakse STLC moodustamiseks
- SDLC hõlmab kogu tarkvara arendamise tsüklit, seevastu STLC hõlmab kõiki testimistsükleid
- SDLC algab planeerimisetapist ja hõlmab kogu arenduse välimust, samas kui STLC algab testi planeerimisega ja hõlmab kõiki testimise aspekte või liike
- Tegevjuht, vanem ärianalüütik, vanemad juhid ja arendajad on inimesed, kes hoolitsevad SDLC all mitme etapi eest. Teisest küljest on QA juht, testianalüütik inimesed, kes juhivad käimasolevat protsessi.
- SDLC käivitub siis, kui tegelikku rakendust pole loodud, kuid STLC käivitub siis, kui tegelik rakendus on olemas või kui töötava tarkvara osa on olemas.
- SDLC on STLC superkomplekt, samas kui STLC on SDLC alamhulk
SDLC vs STLC võrdlustabel
Vaatame ülemist võrdlust SDLC ja STLC vahel -
|
SDLC ja STLC võrdluse alus |
SDLC |
STLC |
| Päritolu | Arengu elutsükkel | Testi elutsükkel |
| Faasid | Kuus faasi
1. Planeerimine 2. Analüüs 3. Kujundus 4. Areng 5. Testimine 6. Hooldus | Kuus faasi
1. Nõuete analüüs 2. Testi planeerimine 3. Testi arendamine 4. Keskkonna seadistamine 5. Testi täitmine 6. Testi sulgemine |
| Suhe | SDLC-d võib pidada lähte- või eelkäijaks. | STLC on järeltulija, kuna tegemist on SDLC-ga. |
| Umbes | See puudutab tarkvara täielikku arendamist, sealhulgas testimist ja muid etappe. | See on mures testimisetapi ja kvaliteedi tagamise osa pärast. |
| Nõuete kogumise etapid | SDLC-s kogub ärianalüütik nõuded, arendustöö teostab arendusmeeskond. | STLC-s teeb testimisrühm pärast testidokumentide analüüsimist töö ülevaatuse, ülevaatuse funktsionaalsest ja mittefunktsionaalsest vaatenurgast. |
| Kavatsus | SDLC eesmärk oli eduka tarkvaraarenduse teel takistustest üle saada. | STLC on mõeldud puuduste või puuduste leidmiseks ainult katsetamisjärgus. |
| Kujundusfaas | SDLC-s on tarkvara kvaliteedi tagamiseks olemas tehniline arhitekt. Siin SDLC ärianalüütik võib aidata tal paremini mõista nõudeid. | STLC-s juhib tegevusi testiarhitekt, testi planeerimine ja kõrgetasemeliste testimispunktide tuvastamine. |
| Kodeerimisetapp | Tegelikud koodid on välja töötatud ja tegelik töö toimub vastavalt kujundatud konstruktsiooni kujule. | Testimisrühm töötab välja testimisplaanide väljatöötamise ja kontrollib tarkvara töökäitumist. Üks asi, mida tuleb märkida, on SDLC-s koodide väljatöötamine, samas kui STLC-de puhul arendatakse ainult testjuhtumeid. |
| Testimisfaas | Testitakse tegelikke koode, mida saavad teha vastastikku arendajad. Selles faasis teostatakse üksuse testimine, integreerimise testimine ja süsteemi testimine. | STLC-s toimub testi täitmine koos aruandlustööga. Üks asi on märkida, et erinevalt kooditestimisest SDLC-s on siin funktsionaalne käitumine ja tarkvara mittefunktsionaalsuse testimine. |
Järeldus - SDLC vs STLC
Arutelu on SDLC vs STLC osas selge. Üks on arengupõhine lähenemisviis ja teine katsetab lähenemisviisi tervikuna. Ehkki testimine kuulub SDLC alla kui ühte jaotist, on oluline tähele panna, et see on väga erinev funktsioon. On väga oluline märkida, et STLC on SDLC all. Igas jaos käsitletavad tegevused on erinevad.
Soovitatavad artiklid
See on juhend SDLC ja STLC vahelise suurima erinevuse kohta. Siin käsitleme ka SDLC vs STLC peamisi erinevusi infograafika ja võrdlustabeliga. Võite lisateabe saamiseks vaadata ka järgmisi artikleid -
- SDLC vs Agile
- Python vs Go
- PL SQL vs SQL
- Agile vs DevOps