Johdanto vesiputousmalliin

Rakennus- ja valmistusteollisuudesta peräisin oleva rakenne on hyvin rakenteellinen fysikaalinen ympäristö, joka on tarkoitettu suunnittelu- ja kehitysprosesseihin. Vesiputousmalli tunnetaan myös ohjelmistokehityksen elinkaarimallina. Se oli ensimmäinen prosessimalli, joka otettiin käyttöön lineaarisen sekvenssin elinkaarimallina. Vesiputomalli kertoo yksinkertaisesti ilmiöstä, että se suorittaa yhden vaiheen kokonaan ennen uuden kehitysvaiheen aloittamista, joten vaiheiden päällekkäisyyttä ei ole. Ohjelmistokehitysalalla vesiputousmallia käytettiin ensin SDLC-lähestymistapana. Jotta vesiputomallia voitaisiin käsitellä, meidän on ymmärrettävä sen soveltamistapa, joka perustuu sekä sisäisiin että ulkoisiin tekijöihin, jotka voivat olla seuraavat:

  • Ei moniselitteisiä vaatimuksia sovelluksessa.
  • Tuotteen määritelmän vakaus
  • Se on tekniikka ymmärretty
  • Se ei ole dynaaminen
  • Tuotteen tukemiseen on käytettävissä suuria resursseja, joilla on asianmukainen asiantuntemus
  • Vey lyhyt projekti
  • Hyvä asiakirja, selkeät ja kiinteät vaatimukset.

Aloittaen vesiputomallin historiasta haluaisin sanoa, että Winston w Royce esitti vuonna 1970 ensimmäisen näytteen vesiputousmallista. Siitä lähtien vesiputousmallissa todetaan, että toisen vaiheen tulisi siirtyä vasta, kun edelliset vaiheet testataan, tarkistetaan ja varmennetaan kokonaan. Siinä korostetaan vaihevaiheiden loogista etenemistä. Sen toiminnallisuus on samanlainen kuin veden virtaus kallion reunan yli. Tälle ohjelmistokehityksen lähestymistavalle on annettu nimi vesiputous, koska se kehittyy systemaattisesti vaiheesta toiseen alaspäin. Siitä lähtien, kun Winston W. Royce julkaisi sen ensimmäisen kerran vuonna 1970, vesiputousmallia on käytetty laajasti ohjelmistokehityksen alalla. Ohjelmistokehitysprosessin aikana ohjelmointimalleja käytetään sovelluksen kehittämisen eri vaiheiden suunnitteluun. Yksi tällainen malli on vesiputousmalli.

Vesiputousmallin vaiheet

Puhutaanko nyt vesiputousmallin vaiheista, jotka selitetään selvästi tämän esittelyinfon avulla.

Yllä olevien infografioiden avulla voimme ymmärtää, että vesiputousmallissa on yhteensä 7 suunnittelu- ja kehitysohjelmistosyklin vaihetta, jotka ovat seuraavat:

  1. vaatimukset
  2. analyysi
  3. Design
  4. Koodaus / toteutus
  5. Testaus
  6. Käyttö / käyttöönotto
  7. ylläpito

Joten voimme nähdä, että vesiputousmalli toimii hierarkiassa ylhäältä alaspäin yhden vaiheen kanssa täydellisillä todentamisilla ja vaihtamalla toiseen vaiheeseen, mukaan lukien vaiheprosessit, kuten suunnittelu, aloittaminen, analysointi, suunnittelu, rakentaminen, testaus, tuotanto / toteutus ja ylläpito. Jotta voimme saada lyhyemmän tiedon vesiputousmallista, meidän on ymmärrettävä kaikki sen prosessit syvällisesti työmallin kanssa. Edellytys on perusvaihe, joka on ymmärrettävä ennen tiedon syvien vaiheiden aloittamista. Kyse on ohjelmistotuotteen toteutettavuustutkimuksesta. Se käsittelee projektivaatimusten taloudellisia ja teknisiä näkökohtia. Tämä vaihe koskee toimenpiteiden korjaamista analysoitujen hyötyjen ja haittojen perusteella. Siksi valitaan paras ratkaisu.

  1. Vaatimukset: Koska sanat täsmentävät, meidän on tiedettävä ja ymmärrettävä, mitä meidän on suunniteltava, mitä meidän on kehitettävä, sen prosessit, mikä on sen toiminnallisuus jne. Se tarjoaa syöttömateriaalia valmistettavaan tuotteeseen ja siten tulevaan tuotteeseen on tutkittu, viimeistelty ja merkitty. Se antaa meille myös laajennuksen päättää tuotteen laitteisto- tai ohjelmistotarpeista, jotka suunnitellaan, kehitetään ja kaappaavat kaikissa vaiheissa.
  2. Analyysi: Tuloksena on mallien, kaavioiden ja liiketoimintasääntöjen suunnittelu. Tämä vaatimus ei ole vain jaettu kahteen osaan:
  • Vaatimuksien kerääminen ja analysointi: Ensin kaikki tuotekehityksen tiedot ja vaatimukset kerätään asiakkaalta ja käsitellään sitten analysointia varten. Tämän osan päätehtävänä on poistaa ohjelmistotuotteiden kehittämiseen liittyvät puutteet ja epäjohdonmukaisuudet.
  • Vaatimusmäärittely: Sitten yllä analysoidut vaatimukset dokumentoidaan SRS-asiakirjaan (ohjelmistovaatimusmäärittely). Se toimii reittinä asiakkaan ja SRS-kehitysryhmän välillä. Tulevaisuuden riitoja hallitaan ja ratkaistaan ​​vain tämän SRS-dokumentoinnin kautta.
  1. Suunnittelu: Kun ensimmäinen vaihe on valmis ja varmennettu, se on seuraava tärkein tutkittava vaihe, koska sitä käytetään järjestelmän suunnitteluun. Se auttaa määrittelemään ohjelmistoa ja laitteistoa koskevat vaatimukset tuotesuunnittelulle. Se auttaa myös järjestelmän suunnittelun kokonaisarkkitehtuurissa. Joten vaatimusmäärittelyä tutkitaan ja todennetaan enimmäkseen tässä vaiheessa. Se on hyödyllinen myös SRS-asiakirjan muuttamisessa ohjelmistotuotteen toiminnalliseen suunnitteluun ja kehittämiseen. Joten voimme sanoa, että suunnitteluvaiheessa tehdään ohjelmistokehitysprojektin kokonaisarkkitehtuuri.
  2. Toteuttaminen: Kun järjestelmän suunnittelu on täysin varmennettu, toteutusvaihe tulee riviin. Tässä vaiheessa otetaan järjestelmäsuunnittelun panokset ja sitä kehitetään ensin pieninä yksiköinä kutsuttuina ohjelmina, jotka testataan ja toteutetaan tulevassa vaiheessa. Jokainen toteutusvaiheen yksikkö kehitetään ja sen koko toimivuus testataan, joka tunnetaan myös nimellä yksikkötestaus. Joten tässä vaiheessa järjestelmän suunnittelu muunnetaan lähdekoodiksi täysin toimivilla ohjelmoduuleilla. Se sisältää ohjelmistojen kehittämisen, todistamisen ja integroinnin.
  3. Integrointi ja testaus: Jokainen yksikön suunnittelu ja aikaisemmissa vaiheissa kehitetty integroidaan toteutusvaiheesta, joka integroidaan moduuliin tai järjestelmään erilaisiin testeihin, kuten kuormitustesti, lyijytesti jne. Kunkin yksikön testauksen jälkeen. Testausympäristö tarkistetaan jatkuvasti ohjelmistolla saadakseen selville, onko suunnittelussa tai koodissa virtauksia tai virheitä. Testaus tehdään ohjelmiston vakauden ja toteutettavuuden ylläpitämiseksi, jotta asiakas ei kohtaa häiriöitä tai virheitä sen valmistuksen aikana. Joten tässä vaiheessa käyttöönoton jälkeen koko järjestelmä testataan perusteellisesti mahdollisten vikojen ja vikojen varalta. Järjestelmätestaus koostuu kolmesta erityyppisestä toiminnasta, jotka voidaan selittää alla:
  • Alfa (α) -testaus: Se on kehitysryhmän suorittama testaus.
  • Beeta (β) -testaus: Testin suorittaa ystävällinen asiakastiimi ja käyttäjät.
  • Hyväksyntätestaus: se tehdään sekä alfa- että beetatestauksen jälkeen. Periaatteessa tämä testaus tehdään asiakkaiden toimituksen jälkeen. Asiakkaan suorittaman testauksen jälkeen päätetään, hyväksytäänkö tämä ohjelmisto vai hylätäänkö se. Joten tässä vaiheessa virheiden virheenkorjaus tehdään periaatteessa.
  1. Järjestelmän käyttöönotto / toiminnot: kun toimimattomat, toiminnalliset, alfa- ja beetatestaukset on suoritettu, ohjelmistotuote siirretään käyttäjä- tai asiakasjärjestelmään tai vapautetaan markkinoille. Asennusvaihe sisältää koko järjestelmän asennuksen, siirron ja tuen käyttäjän tai asiakasympäristöön.
  2. Huolto: Se on viimeinen, mutta tärkein vaihe vesiputousprosessin mallissa. Tämä vaihe tulee heti asennuksen jälkeen, ja siihen sisältyy asianmukaisten muutosten tekeminen tuotteeseen tai järjestelmään tai järjestelmään liittyvien suorituskykyongelmien ominaisuuksien parantaminen, muuttaminen tai muuttaminen. sen päätehtävänä on parantaa järjestelmän suorituskykyä ohjelmistolähdön parhaalla mahdollisella tarkkuudella. Nämä ylläpitovaiheessa esiin tuodut muutokset liittyvät pääasiassa muutoksiin, jotka asiakas tai käyttäjät tekevät asennuksen ja testauksen jälkeen, joihin sisältyy virheitä, kuten järjestelmän reaalikäytössä havaitut viat tai asiakkaiden esittämät pyynnöt. Joten asiakkaalle tarjotaan oikea-aikainen ja suunniteltu huolto ja tuki kehitetylle tuotteelle. Saatat todella hämmästymään tietäessäsi, että ohjelmistotuotteen suunnittelu- ja kehitysvaiheessa ponnistelu on vain 60% verrattuna ylläpitovaiheeseen tehtyihin ponnisteluihin. Periaatteessa on kolme huoltotyyppiä, jotka selitetään alla:
  • Korjaava ylläpito: Suunnittelu- ja kehitysvaiheessa joitain virheitä ei löydy, ne otetaan huomioon vain asiakkaan käyttäessä. Tämä on vain korjaava ylläpito, mikä tarkoittaa niiden virheiden tai virheiden korjaamista, joita ei löydy kehitysvaiheessa.
  • Täydellinen kunnossapito: Tämän tyyppinen ylläpito suoritetaan asiakkaan pyynnöstä järjestelmän tai ohjelmiston toimintojen parantamiseksi ja parantamiseksi.
  • Mukautuva ylläpito: Järjestelmän vaihtamiseen vaaditaan ylläpito. Yleensä tarvitaan olemassa olevan järjestelmän siirtämiseen uuteen ympäristöön tai uuteen tietokoneeseen tai järjestelmään tai ehkä uuden käyttöjärjestelmän kanssa. Tämä vaihe on liian tärkeä, koska se parantaa järjestelmän suorituskykyä.

Joten yllä olevassa keskustelussa saimme tuntea jokaisen vesiputomallin vaiheen syvästi täydellisillä vaatimuksilla. Joten voimme sanoa, että vesiputomalli on erittäin tärkeä ohjelmistoalalla myös mekaaniseen teollisuuteen verrattuna, koska jokaisella vaiheella on oma merkityksensä, joten se tuottaa tuottavamman ja vakaamman ohjelmiston.

edut

Paitsi tällä vesiputousmallilla on myös paljon enemmän etuja ohjelmistokehityksen elinkaaren aikana, joista voidaan keskustella alla:

  • Se mahdollistaa osastoinnin ja hallinnan.
  • Aikataulu voidaan asettaa määräajoin jokaiselle kehitysvaiheelle ja tuote voi edetä kehitysprosessimallivaiheissa yksi kerrallaan.
  • Koska se käy läpi helposti ymmärrettävät ja selitettävät vaiheet, se voittaa monia asioita, joten sitä on erittäin helppo käyttää.
  • Työnkulkumallin jäykkyyden vuoksi sitä on erittäin helppo hallita, koska vesiputousmallin jokaisella vaiheella on erityiset tarkistus- ja toimitusprosessit.
  • Vesiputousmalli toimii hyvin pienissä projekteissa, joissa vaatimukset ymmärretään hyvin.
  • Aikataulu voidaan asettaa määräajoin jokaiselle kehitysvaiheelle ja tuote voi edetä kehitysprosessimallivaiheissa yksi kerrallaan.
  • Selkeästi määritellyt vaiheet.
  • Hyvin ymmärretyt välitavoitteet.
  • Helppo järjestää tehtäviä.
  • Prosessi ja tulokset on dokumentoitu hyvin.
  • Vahvistaa hyviä tapoja: määrittele ennen suunnittelua,
  • Suunnittelu-ennen-koodia.
  • Malli toimii hyvin pienissä projekteissa ja projekteissa, joissa vaatimukset ymmärretään hyvin.

haitta

Kuten tiedämme, että jokaisella kolikolla on kaksi puolta, joten vesiputousmallilla on laaja pääsy vesiputousmallin etuihin, sillä on myös joitain haittoja tai voit sanoa haitat, joista keskustellaan alla:

  • Ei hyvä malli monimutkaisille ja oliopohjaisille hankkeille.
  • Ei sovellu hankkeisiin, joissa vaatimusten muuttumisriski on kohtalaisesta korkeaan.
  • Aikaa ja kustannuksia on vaikea arvioida jokaisesta kehitysprosessin vaiheesta.
  • Ei hyvä malli monimutkaisille ja oliopohjaisille hankkeille.
  • Toimivia ohjelmistoja ei tuoteta myöhään elinkaaren aikana.
  • Ei sovi muuttuviin vaatimuksiin.
  • Edistymistä on vaikea mitata vaiheittain.
  • Suuri riski ja epävarmuus.
  • Huono malli pitkille ja meneillään oleville hankkeille.
  • Laajennuksen säätäminen elinkaaren aikana voi lopettaa projektin.
  • Ei palautetta
  • Ei vaiheiden päällekkäisyyttä
  • Vaikea mukauttaa muutospyyntöjä.
  • riski ja epävarmuus ovat korkeat tässä prosessimallissa.

Missä käyttää vesiputousmallia

Nyt kun ympäröimme kaikki skenaariot, tulemme pisteeseen, jossa haluamme tietää missä vesiputomallia käytetään.

  • Puolustushankkeessa käytetään pääosin vesiputousmallia, koska siellä vaatimus on selvä, koska he analysoivat sen hyvin ennen kehitysvaiheeseen siirtymistä.
  • Tätä voidaan käyttää myös siirtohankkeissa, joissa vaatimukset ovat sama ainoa alusta tai kielet voivat vaihdella / muuttua.

johtopäätös

Joten kokonaisuudessaan voin sanoa, että vesiputomalli soveltuu parhaiten pieniin ohjelmistokehitysprojekteihin verrattuna suuriin projekteihin, koska pienessä projektissa suunnittelu, kehittäminen ja toteuttaminen on helpompaa vesiputousmallin parissa, koska tässä mallissa kaikki aiemmat vaiheet tarvitsevat valmistuu, kun siirrytään tuleviin vaiheisiin. Joten isossa projektissa ongelmia ja virheitä esiintyy usein, koska siinä on suuri malli, joten testausvaihetta jatketaan joka kerta, jos se toteutetaan vesiputousmallin kautta, mikä johtaa ohjelmiston vähemmän optimointiin ja tarkkuuteen.

Suositellut artikkelit

Tämä on ollut opas vesiputousmalliin. Tässä olemme keskustelleet vesiputousmallin vaiheista, eduista ja haitoista. Voit myös käydä läpi muiden ehdotettujen artikkeleidemme saadaksesi lisätietoja -

  1. Mikä on AWS?
  2. Mikä on Bootstrap?
  3. Mikä on pesä?
  4. Mikä on Unix?
  5. Scrum vs vesiputous | Vertailu

Luokka:

Ohjelmistokehitys