Sissejuhatus jugamudelisse

See on ehitus- ja töötleva tööstuse päritoluga struktureeritud füüsiline keskkond, mis on mõeldud projekteerimis- ja arendusprotsesside jaoks. Jugamudelit tuntakse ka tarkvaraarenduse elutsüklimudelina. See oli esimene protsessimudel, mis võeti kasutusele lineaarse järjestikuse olelustsükli mudelina. Jugamudel kirjeldab nähtust lihtsalt, et üks etapp tuleb enne uue arendusetapi alustamist täielikult lõpule viia, nii et faasid ei kattuks. Tarkvaraarenduse valdkonnas kasutati SDLC lähenemisena esmakordselt jugamudelit. Jugamudeli väljatöötamiseks peame mõistma selle rakendamisviisi, mis põhineb nii sisemistel kui ka välistel teguritel, mis võivad olla järgmised:

  • Rakenduses puuduvad mitmetähenduslikud nõuded.
  • Toote määratluse stabiilsus
  • See on tehnoloogia mõistmine
  • See pole dünaamiline
  • Toote toetamiseks on saadaval suured ressursid koos asjakohaste teadmistega
  • Vey lühikese pikkusega projekt
  • Hea dokument, selged ja fikseeritud nõuded.

Alustades jugamudeli ajaloost, tahaksin öelda, et jugamudeli esimese proovi tutvustas Winston w Royce 1970. aastal oma artiklis. Pärast seda on jugamudelis öeldud, et üks peaks teise faasi minema ainult siis, kui eelmisi faase on täielikult testitud, üle vaadatud ja kinnitatud. See rõhutab etappide loogilist progresseerumist. Selle funktsionaalsus on sarnane veega, mis voolab üle kaljuserva. Sellele tarkvaraarenduse lähenemisviisile on antud nimetus juga, kuna see areneb süstemaatiliselt ühest etapist teise allapoole. Alates ajast, kui Winston W. Royce selle 1970. aastal esmakordselt avaldas, on jugamudelit tarkvaraarenduse valdkonnas laialdaselt kasutatud. Tarkvaraarendusprotsesside tsüklis kasutatakse programmeerimismudeleid rakenduse väljatöötamise erinevate etappide kavandamiseks. Üks selline mudel on jugamudel.

Juga mudeli faasid

Räägime nüüd jugamudeli faasidest, mida saab selle demoinfograafia abil selgelt selgitada.

Ülaltoodud infograafika abil saame aru, et jugamudelil on kokku 7 projekteerimise ja arendamise tarkvaratsüklit, mis on järgmised:

  1. Nõuded
  2. Analüüs
  3. Kujundus
  4. Kodeerimine / juurutamine
  5. Testimine
  6. Operatsioon / juurutamine
  7. Hooldus

Nii näeme, et jugamudel töötab hierarhiliselt ülalt alla, kusjuures üks faas on lõpule viidud täielike kontrollimistega, seejärel minnakse üle teisele faasile, mis hõlmab ka selliseid faasiprotsesse nagu kontseptsioon, algatamine, analüüs, projekteerimine, ehitamine, testimine, tootmine / juurutamine ja hooldus. Jugamudeli kohta lühimate teadmiste saamiseks peame mõistma kõiki selle protsesse oma töömudeliga sügavuti. Enne teadmiste sügavate faaside alustamist tuleb mõista eeltingimust. See puudutab tarkvaratoote teostatavusuuringut. See tegeleb projektinõuete rahaliste ja tehniliste aspektidega. Selles etapis käsitletakse meetmete parandamist analüüsitud eeliste ja puuduste põhjal. Seega valitakse parim lahendus.

  1. Nõuded: Kuna see on sõnadega konkreetne, peame teadma ja mõistma, mida peame kavandama, mida peame arendama, selle protsesse, milline on selle funktsionaalsus jne. See annab sisendmaterjali valmistatavale tootele ja seega ka tulevale tootele uuritakse, vormistatakse ja tähistatakse. See annab meile ka laienduse, mis võimaldab otsustada toote riist- või tarkvara osas, mis kavandatakse, arendatakse ja hõivatakse kõigis etappides.
  2. Analüüs: selle tulemuseks on mudelite, skeemide ja ärireeglite kujundamine. See nõue pole mitte ainult jagatud kaheks osaks:
  • Nõuete kogumine ja analüüs: kõigepealt kogutakse kliendilt kogu teave ja nõuded tootearenduseks ning seejärel töödeldakse seda analüüsimiseks. Selle osa põhiroll on likvideerida tarkvaratoote arendamisega seotud puudulikkus ja vastuolud.
  • Nõude spetsifikatsioon: Seejärel dokumenteeritakse ülaltoodud analüüsitud nõuded SRS-i (tarkvara nõude spetsifikatsioon) dokumenti. See on tee kliendi ja SRS-i arendusmeeskonna vahel. Edasisi vaidlusi hallatakse ja lahendatakse ainult selle SRS-i dokumentatsiooni kaudu.
  1. Kujundus: pärast esimese etapi valmimist ja kontrollimist on see järgmine kõige olulisem uuritav etapp, kuna seda kasutatakse süsteemi kujundamisel. See aitab täpsustada tootekujundusele esitatavaid tarkvara- ja riistvaranõudeid. See aitab ka süsteemi projekteerimisel üldises arhitektuuris. Nii et selles etapis uuritakse ja kontrollitakse enamasti nõude spetsifikatsiooni. See on abiks ka SRS-dokumendi muutmisel tarkvaratoote funktsionaalseks kujundamiseks ja arendamiseks. Nii võime öelda, et projekteerimisetapis tehakse tarkvaraarendusprojekti üldist arhitektuuri.
  2. Rakendamine: kui süsteemi ülesehitus on täielikult kontrollitud, tuleb kasutusele võtmise etapp järjest. Selles faasis võetakse kasutusele süsteemi projekteerimise sisendid ja see töötatakse kõigepealt välja väikestes programmides, mida nimetatakse ühikuteks, mida testitakse ja rakendatakse eelseisvas etapis. Rakendusetapi iga üksus töötab välja ja testitakse selle täielikku funktsionaalsust, mida nimetatakse ka üksuse testimiseks. Nii et selles faasis muudetakse süsteemi kujundus täielikult funktsionaalsete programmimoodulitega lähtekoodiks. See hõlmab tarkvara arendamist, tõestamist ja integreerimist.
  3. Integreerimine ja testimine: iga varasemates etappides väljatöötatud ja välja töötatud üksus integreeritakse rakendusfaasist, mis on pärast iga üksuse testimist integreeritud moodulisse või süsteemi mitmesugusteks katseteks, nagu koormustesti, plii test jne. Testimiskeskkond kontrollib tarkvara pidevalt, et teada saada, kas kujunduses või koodis on vooge või vigu. Testimine toimub tarkvara stabiilsuse ja teostatavuse säilitamiseks, nii et klient ei peaks selle tootmise ajal ilmnema häireid ega vigu. Nii et selles etapis pärast juurutamist testitakse kogu süsteemi põhjalikult võimalike tõrgete ja tõrgete suhtes. Süsteemi testimine koosneb kolmest erinevat tüüpi tegevusest, mida saab selgitada järgmiselt:
  • Alfa (α) testimine: see on arendusmeeskonna testimine.
  • Beeta (β) testimine: see on testimine, mida teevad klientide ja kasutajate sõbralik meeskond.
  • Vastuvõtu testimine: seda tehakse nii pärast alfa- kui ka beetatesti. Põhimõtteliselt tehakse seda testimist pärast klientide poolt tarnimist. Pärast kliendi tehtud testimist võetakse vastu otsus, kas see tarkvara on vastuvõetav või lükatakse see tagasi. Selles etapis tehakse põhimõtteliselt veade silumist.
  1. Süsteemi juurutamine / toimingud: kui mittefunktsionaalsed, funktsionaalsed, alfa- ja beetatestid on läbi viidud, juurutatakse tarkvara toode kasutaja või kliendi süsteemi või lastakse turule. Kasutuselevõtufaas hõlmab kogu süsteemi installimist, migreerimist ja toetamist kasutaja või kliendi keskkonda.
  2. Hooldus: see on juga töövoo mudeli viimane, kuid kõige olulisem etapp. See samm tuleb kohe pärast installimist ja see hõlmab toote või süsteemi sobivate muudatuste tegemist või süsteemi jõudlusega seotud atribuutide täiustamist, muutmist või muutmist. selle peamine roll on süsteemi jõudluse parandamine tarkvaraväljundi maksimaalse täpsusega. Need hooldusetapis tõstatatud muudatused on peamiselt seotud muudatustega, mille klient või kasutajad peavad tegema pärast installimise ja testimise etappi, sealhulgas vead, näiteks süsteemi reaalajas kasutamisel avastatud defektid või klientide üleskutse. Nii pakutakse kliendile väljaarendatud toote õigeaegset ja planeeritud hooldust ning tuge. Teid hämmastab tõepoolest teadmine, et tarkvaratoote kavandamise ja arendamise etapis tehtavad jõupingutused on ainult 60%, võrreldes hooldusfaasis tehtud pingutustega. Põhimõtteliselt on kolme tüüpi hooldust, mida selgitatakse allpool:
  • Korrigeeriv hooldus: projekteerimis- ja arendusetapis ei avastata mõnda viga, neid võetakse arvesse ainult siis, kui klient seda kasutab. See on ainult korrigeeriv hooldus, mis tähendab nende probleemide või vigade parandamist, mida arendusetapis ei avastatud.
  • Täiuslik hooldus: seda tüüpi hooldustöid tehakse kliendi soovil, et süsteemi või tarkvara funktsionaalsusi suurendada ja täiustada.
  • Adaptiivne hooldus: süsteemikeskkonna vahetamiseks on vajalik hooldus. Tavaliselt on vaja olemasoleva süsteemi teisaldamiseks uude keskkonda või uude arvutisse või süsteemi või võib-olla ka uue opsüsteemi. See etapp on liiga oluline, kuna see toob kaasa süsteemi parema jõudluse.

Nii et ülaltoodud arutelus saime tuttavaks jugamudeli iga etapiga sügavuti täielike spetsifikatsioonidega. Seega võime öelda, et jugamudel on tarkvara valdkonnas väga oluline ka mehaanikatööstustega võrreldes, kuna igal etapil on oma tähtsus, ja see tekitab tootlikuma ja stabiilsema tarkvara.

Eelised

Sellel jugamudelil on tarkvara arendamise elutsüklis ka palju rohkem eeliseid, mida saab käsitleda allpool:

  • See võimaldab osakondade jaotamist ja kontrolli.
  • Igale arenguetapile saab seada ajakava ja toode võib ükshaaval läbi viia arendusprotsessi mudeli faase.
  • Kuna see läbib kergesti mõistetavad ja seletatavad etapid, ületab see paljusid probleeme, seega on seda väga lihtne kasutada.
  • Töövoo mudeli jäikuse tõttu on seda väga lihtne hallata, kuna jugamudeli igal etapil on konkreetsed ülevaatamis- ja edastamisprotsessid.
  • Jugamudel sobib hästi väiksemate projektide jaoks, kus nõuetest on väga hästi aru saadud.
  • Ajakava saab seada tähtaegadega iga arenguetapi jaoks ja toode võib ükshaaval läbi viia arendusprotsessi mudeli faase.
  • Selgelt määratletud etapid.
  • Hästi mõistetavad verstapostid.
  • Lihtne ülesandeid korraldada.
  • Protsess ja tulemused on hästi dokumenteeritud.
  • Tugevdab häid harjumusi: määratle enne kujundamist,
  • Kujunda enne koodi.
  • Mudel töötab hästi väiksemate projektide ja projektide puhul, kus nõuetest on hästi aru saadud.

Puuduseks

Kuna me teame, et igal mündil on kaks külge, on jugamudelil ka suurte puuduste olemasolul juurdepääs puudustele või võite öelda puudusi, mida arutatakse allpool:

  • Pole hea mudel keerukate ja objektorienteeritud projektide jaoks.
  • Ei sobi projektide jaoks, mille nõuete muutmise oht on mõõdukast kuni kõrgeni.
  • Arendusprotsessi igas etapis on keeruline aega ja kulusid hinnata.
  • Pole hea mudel keerukate ja objektorienteeritud projektide jaoks.
  • Ühtegi töötavat tarkvara ei toodeta elutsükli hilisõhtul.
  • Ei sobi muutuvate nõuetega.
  • Etappide kaupa on edusamme keeruline mõõta.
  • Suur risk ja ebakindlus.
  • Halb mudel pikkadele ja käimasolevatele projektidele.
  • Ulatuse kohandamine olelustsükli jooksul võib projekti lõpetada.
  • Tagasiside puudub
  • Faaside kattumine puudub
  • Raske kohandada muudatuste taotlusi.
  • selle protsessimudeli puhul on risk ja ebakindlus kõrge.

Kus kasutada jugamudelit

Pärast kõigi stsenaariumide ümbritsemist jõuame punkti, kus tahame teada, kus jugamudelit kasutada.

  • Kaitseprojektis kasutatakse peamiselt jugamudelit, kuna seal on nõue selge, sest enne arendusetappi siirdumist analüüsivad nad seda hästi.
  • Seda saab kasutada ka migratsiooniprojektides, kus nõuded on samad, ainult platvorm või keeled võivad erineda / muutuda.

Järeldus

Nii et tervikuna võin öelda, et jugamudel sobib väikeste tarkvaraarendusprojektide jaoks kõige paremini võrreldes suurte projektidega, kuna jugamudeliga töötades on väikeses projektis hõlpsam kujundada, arendada ja juurutada, kuna selles mudelis on vaja kõiki eelnevaid faase tuleb eelseisvatesse faasidesse minnes lõpule viia. Nii et suures projektis ilmnevad probleemid ja vead sageli, kuna sellel on suur mudel, nii et testimise etappi jätkatakse iga kord, kui seda jugamudeli kaudu rakendada, mis viib tarkvara vähem optimeerimiseni ja täpsuseni.

Soovitatavad artiklid

See on juhend Waterfall Model. Siin oleme arutanud jugamudeli faase, eeliseid ja puudusi. Lisateavet leiate ka meie muudest soovitatud artiklitest -

  1. Mis on AWS?
  2. Mis on Bootstrap?
  3. Mis on taru?
  4. Mis on Unix?
  5. Scrum vs juga | Võrdlus

Kategooria:

Tarkvaraarendus