Увод у модел водопада

Потјече из грађевинске и производне индустрије, високо је структурирано физичко окружење намијењено процесима дизајна и развоја. Модел водопада познат је и као модел животног циклуса развоја софтвера. То је први модел процеса уведен као линеарно-секвенцијални модел животног циклуса. Модел водопада једноставно говори феномену да се једна фаза у потпуности заврши пре започињања нове фазе развоја, тако да нема преклапања фаза. У пољу развоја софтвера, водопадни модел је први пут коришћен као СДЛЦ приступ. Да бисмо радили на моделу водопада, морамо да разумемо његов апликативни приступ заснован на унутрашњим и спољним факторима који могу бити следећи:

  • У апликацији нема двосмислених захтева.
  • Стабилност дефиниције производа
  • То је технологија схваћена
  • Није динамична
  • На располагању су велики ресурси с одговарајућом експертизом за подршку производу
  • Веи пројекат кратке дужине
  • Добар документ, јасни и фиксни захтеви.

За почетак са историјом модела водопада, желео бих да кажем да је први узорак модела водопада изнео 1970. године Винстон в Роице у једном чланку. Од тада модел слапа каже да би требало прећи на другу фазу тек када су претходне фазе у потпуности тестиране, прегледане и верификоване. Наглашава се на логичном напредовању фазних корака. Његова функционалност је слична струји воде преко ивице литице. Овакав приступ развоју софтвера добио је име водопад, јер се систематски развија из једне фазе у другу на силазни начин. Од времена када га је 1970. први пут објавио Винстон В. Роице, модел водопада широко се користио у области развоја софтвера. У циклусу процеса развоја софтвера, програмски модели се користе за планирање различитих фаза развоја апликације. Један такав модел је модел водопада.

Фазе модела водопада

Сада разговарајмо о фазама модела водопада, што се може јасно објаснити кроз ову демо инфографику.

Помоћу горње инфографике можемо разумети да модел водопада има укупно 7 фаза циклуса дизајна и развоја софтвера који су следећи:

  1. Захтеви
  2. Анализа
  3. Дизајн
  4. Кодирање / имплементација
  5. Тестирање
  6. Рад / распоређивање
  7. Одржавање

Тако можемо видети да модел водопада ради хијерархијом од врха до дна, а једна фаза је завршена потпуним верификацијама, а затим прелази на другу фазу, укључујући фазне процесе попут концепције, иницијације, анализе, дизајна, конструкције, испитивања, производње / имплементације и одржавања. Да бисмо стекли краће знање о моделу водопада, морамо дубоко разумети све његове процесе са његовим радним моделом. Постоји основна претпоставка фаза коју треба схватити пре него што започнемо дубоке фазе знања. Ријеч је о студији изводљивости за софтверски производ. Бави се финансијским и техничким аспектима пројектних захтева. Ова фаза се бави корекцијом мера на основу анализираних предности и недостатака. Тако је изабрано најбоље решење.

  1. Захтеви: Као што је специфично по речима, морамо знати и разумети шта морамо да дизајнирамо, шта морамо да развијемо, његове процесе, која ће бити његова функционалност итд. Омогућава улазни материјал производу који се прави и самим тим надолазећем производу се проучава, финализира и обележава. Такођер нам омогућава проширење за одлучивање о хардверским или софтверским захтјевима производа који ће бити дизајнирани, развијени и снимљени у свим фазама.
  2. Анализа: Резултат је дизајнирања модела, шема и пословних правила. Не само да је овај захтев подељен на два дела:
  • Прикупљање и анализа захтева: Прво се све информације и захтеви за развој производа прикупе од купца, а затим се обрађују на анализу. Главна улога овог дела је уклањање непотпуности и недоследности у вези са развојем софтверских производа.
  • Спецификација захтева: Затим су горе анализирани захтеви документовани у документу СРС (спецификација софтверског захтева). Служи као пут између купца и СРС развојног тима. Било какви спорови у будућности се рјешавају и рјешавају само кроз ову СРС документацију.
  1. Дизајн: Након завршетка и верификације прве фазе то је следећа најважнија фаза која се проучава јер се користи за пројектовање система. Помаже у одређивању софтверског и хардверског захтева за дизајн производа. Такође помаже у укупној архитектури за дизајн система. Дакле, спецификација захтева се углавном проучава и проверава у овој фази. Такође је корисно у претварању СРС документа у функционални дизајн и развој софтверског производа. Тако да можемо рећи да се у фази дизајнирања ствара цјелокупна архитектура пројекта развоја софтвера.
  2. Имплементација: Када је системски дизајн потпуно верификован, фаза имплементације долази у ред. У овој фази се узимају инпути из дизајна система, а прво се развија у малим програмима познатим као јединице, који се тестира и примењује у наредној фази. Свака јединица у фази имплементације пролази кроз развој и тестира се њена пуна функционалност, која је позната и као тестирање јединице. У овој фази, дизајн система се претвара у изворни код са потпуно функционалним програмским модулима. То укључује развој, доказивање и интеграцију софтвера.
  3. Интеграција и тестирање: Свака конструкција јединице и развијена у ранијим фазама укључена је из фазе примене која је интегрисана у модул или систем за различите тестове попут испитивања оптерећења, испитивања олова итд. Након тестирања сваке јединице. Околина за тестирање пролази кроз сталну проверу софтвера како би се утврдило да ли у дизајну или коду има протока или грешака. Тестирање се ради како би се одржала стабилност и изводљивост софтвера тако да се клијент не суочи са сметњама или грешкама током производње. У овој фази након примене, цео систем се темељно тестира на било какве грешке и кварове. Тестирање система састоји се од три различите врсте активности које се могу објаснити као доле:
  • Алпха (α) Тестирање: То је тестирање које је урадио развојни тим.
  • Бета (β) тестирање: То је тестирање пријатељског тима купаца и корисника.
  • Испитивање прихватања: врши се након алфа тестирања и бета тестирања. У основи, ово тестирање се врши након испоруке од стране купаца. Након тестирања које извршава купац, доноси се одлука да ли је овај софтвер прихватљив или га одбити. Дакле, у овој фази се у основи врши уклањање грешака.
  1. Употреба система / Операције: једном када се нефункционално, функционално, алфа и бета тестирање заврши, производ софтвера ће бити распоређен на систем корисника или купца или је пуштен на тржиште. Фаза имплементације укључује инсталацију, миграцију и подршку комплетног система корисничком или корисничком окружењу.
  2. Одржавање: То је последња, али најважнија фаза у моделу тока рада водопада. Овај корак долази одмах након инсталације и укључује уношење одговарајућих промена на производ или систем или за побољшање, промену или измену атрибута који се односе на проблем перформанси у вези са системом. његова главна улога је да побољша перформансе система уз максималну тачност резултата софтвера. Ове промене које су подигнуте током фазе одржавања углавном су повезане са променама које је иницирао купац или корисници након фазе инсталације и тестирања, а које укључују грешке попут оштећења откривених током активног коришћења система или захтева који су поставили купци. Тако се клијенту пружа правовремено и планирано одржавање и подршка за развијени производ. Заиста ћете бити запрепаштени када знате да је труд уложен у фазу дизајнирања и развоја софтверског производа само 60% напора у односу на напоре уложене у фази одржавања. У основи постоје три врсте одржавања што је објашњено у наставку:
  • Корективно одржавање: Током фазе дизајнирања и развоја неке грешке се не открију, оне се узимају у обзир само када корисник користи. Ово је само корективно одржавање што значи исправљање проблема или грешака који нису откривени у фази развоја.
  • Савршено одржавање: Ова врста одржавања врши се на захтев купца ради повећања и унапређења функционалности система или софтвера.
  • Прилагодљиво одржавање: одржавање је неопходно за пребацивање окружења система. Обично је потребно за пренос постојећег система у ново окружење или нови рачунар или систем или можда са новим оперативним системом. Ова фаза је превише важна, јер доводи до бољих перформанси система.

Тако смо у горњој дискусији дубоко упознали сваку фазу модела водопада са потпуним спецификацијама. Дакле, можемо рећи да је водопадни модел веома важан у софтверској области иу поређењу са механичком индустријом, јер свака фаза има своју важност, доводи до стварања продуктивнијег и стабилнијег софтвера.

Предности

Не само да овај модел водопада има и много више предности у животном циклусу развоја софтвера о којима може бити речи у наставку:

  • Омогућује департментализацију и контролу.
  • Распоред се може поставити са роковима за сваку фазу развоја и производ може проћи кроз фазе развојног процеса једну по једну.
  • Како пролази кроз лако разумљиве и разумљиве фазе, превазилази многа питања, па је веома једноставан за употребу.
  • Због крутости модела тока рада, врло је лако управљати јер свака фаза у моделу водопада има специфичне процесе прегледа и резултата.
  • Водопадни модел добро функционише за мање пројекте где су захтеви веома добро разумљиви.
  • Распоред се може поставити са роковима за сваку фазу развоја и производ може проћи кроз фазе развојног процеса, једну по једну.
  • Јасно дефинисане фазе.
  • Добро схваћене прекретнице.
  • Лако за сређивање задатака.
  • Процес и резултати добро су документовани.
  • Појачава добре навике: дефинишите пре дизајна,
  • Дизајн пре кода.
  • Модел делује добро за мање пројекте и пројекте где су захтеви добро разумети.

Недостатак

Као што знамо да сваки новчић има два лица, тако да због великог приступа предностима модела водопада, модел водопада има и неке недостатке или можете рећи недостатке који су дискутовани у наставку:

  • Није добар модел за сложене и објектно оријентисане пројекте.
  • Није погодно за пројекте у којима су захтеви умерени до високи ризик промене.
  • Тешко је проценити време и трошкове за сваку фазу развојног процеса.
  • Није добар модел за сложене и објектно оријентисане пројекте.
  • Ниједан радни софтвер се не производи до касно током животног циклуса.
  • Не могу да одговоре захтевима који се мењају.
  • Тешко је мерити напредак у фазама.
  • Високе количине ризика и несигурности.
  • Лош модел за дуге и текуће пројекте.
  • Подешавањем обима током животног циклуса може се завршити пројекат.
  • Нема повратних информација
  • Нема преклапања фаза
  • Тешко удовољити захтевима за промену.
  • ризик и несигурност су високи код овог процеса процеса.

Где користити модел водопада

Сада након заокруживања свих сценарија, дошли смо до тачке у којој желимо знати где се користи модел водопада.

  • Модел водопада се углавном користи у одбрамбеном пројекту, захтев је јасан јер пре него што пређу у фазу развоја добро га анализирају.
  • Ово се такође може користити у пројектима миграције где ће захтеви бити исти, а само се платформа или језици могу мењати / мењати.

Закључак

Тако да у целини могу рећи да је водопадни модел најприкладнији за мали пројекат развоја софтвера у поређењу са великим пројектима, јер је дизајн, развој и примена лакши у малом пројекту када се ради на моделу водопада, јер су у овом моделу потребне све претходне фазе да се заврши при предстојећим фазама. Дакле, у великом пројекту проблеми и грешке се јављају често јер има велики модел, тако да ће се сваки пут фаза тестирања наставити ако се имплементира кроз модел водопада, што ће довести до мање оптимизације и тачности софтвера.

Препоручени чланци

Ово је водич за модел водопада. Овде смо разговарали о фазама, предностима и недостацима модела водопада. Можете и да прођете кроз друге наше предложене чланке да бисте сазнали више -

  1. Шта је АВС?
  2. Шта је Боотстрап?
  3. Шта је кошница?
  4. Шта је Уник?
  5. Сцрум вс Ватерфалл | Поређење

Категорија:

Развој софтвера