Метадалогіі распрацоўкі праграмнага забеспячэння

У гэтым паведамленні мы разгледзім розныя метадалогіі распрацоўкі праграмнага забеспячэння, а таксама іх перавагі і недахопы і час выкарыстання кожнай мадэлі.



Ітэратыўная мадэль

Ітэрацыйная мадэль жыццёвага цыкла не спрабуе пачаць з поўнай спецыфікацыі патрабаванняў. Замест гэтага распрацоўка пачынаецца з указання і ўкаранення толькі часткі праграмнага забеспячэння, якое потым можна перагледзець з мэтай вызначэння далейшых патрабаванняў. Затым гэты працэс паўтараецца, вырабляючы новую версію праграмнага забеспячэння для кожнага цыкла мадэлі.

Разгледзім ітэрацыйную мадэль жыццёвага цыкла, якая складаецца з паўтарэння наступных чатырох фаз паслядоўна:


Фаза патрабаванняў, у якім збіраюцца і аналізуюцца патрабаванні да праграмнага забеспячэння. Ітэрацыя ў выніку павінна прывесці да фазы патрабаванняў, якая стварае поўную і канчатковую спецыфікацыю патрабаванняў.

Фаза дызайну, у якім распрацавана праграмнае рашэнне для задавальнення патрабаванняў. Гэта можа быць новы дызайн альбо пашырэнне ранейшага дызайну.


Фаза ўкаранення і тэставання, калі праграмнае забеспячэнне кадуецца, інтэгруецца і тэстуецца.



Этап агляду, у якіх ацэньваецца праграмнае забеспячэнне, разглядаюцца бягучыя патрабаванні і прапануюцца змены і дапаўненні да патрабаванняў.

Для кожнага цыкла мадэлі павінна быць прынята рашэнне аб тым, ці будзе праграмнае забеспячэнне, якое вырабляецца ў рамках цыкла, адкінута альбо захавана ў якасці адпраўной кропкі для наступнага цыкла (часам яго называюць паступовым прататыпаваннем).

У рэшце рэшт будзе дасягнута кропка, калі патрабаванні поўныя і праграмнае забеспячэнне можа быць пастаўлена, альбо становіцца немагчымым пашырыць праграмнае забеспячэнне па меры неабходнасці, і трэба пачаць новы старт.


Ітэратыўную мадэль жыццёвага цыклу можна параўнаць з выпрацоўкай праграмнага забеспячэння шляхам паслядоўнага набліжэння. Праводзячы аналогію з матэматычнымі метадамі, якія выкарыстоўваюць паслядоўнае набліжэнне, каб знайсці канчатковае рашэнне, карысць такіх метадаў залежыць ад таго, наколькі хутка яны збліжаюцца з рашэннем.

Ключом да паспяховага выкарыстання ітэрацыйнага жыццёвага цыкла распрацоўкі праграмнага забеспячэння з'яўляецца строгая праверка патрабаванняў і праверка (уключаючы тэставанне) кожнай версіі праграмнага забеспячэння на адпаведнасць гэтым патрабаванням у рамках кожнага цыкла мадэлі.

Перавагі ітэратыўнай мадэлі

  • Хутка і рана генеруе працуючае праграмнае забеспячэнне на працягу жыццёвага цыкла праграмнага забеспячэння.
  • Больш гнуткі - менш затратны для змены сферы прымянення і патрабаванняў.
  • Прасцей тэставаць і адладжваць падчас меншай ітэрацыі.
  • Кіраваць рызыкай лягчэй, таму што падчас ітэрацыі ідэнтыфікуюцца рызыкоўныя часткі.
  • Кожная ітэрацыя - важны этап кіравання.

Недахопы ітэратыўнай мадэлі

  • Кожная фаза ітэрацыі жорсткая і не перакрывае адна адну.
  • Могуць узнікнуць праблемы, звязаныя з архітэктурай сістэмы, бо не ўсе патрабаванні сабраны загадзя на працягу ўсяго жыццёвага цыкла праграмнага забеспячэння.


Інкрэментальная мадэль

Мадэль паступовай зборкі - гэта метад распрацоўкі праграмнага забеспячэння, пры якім мадэль распрацоўваецца, укараняецца і выпрабоўваецца паступова (кожны раз дадаецца крыху больш), пакуль прадукт не скончыцца. Гэта прадугледжвае як распрацоўку, так і тэхнічнае абслугоўванне. Прадукт вызначаецца як гатовы, калі ён задавальняе ўсім яго патрабаванням. Гэтая мадэль спалучае ў сабе элементы мадэлі вадаспада з ітэратыўнай філасофіяй прататыпавання.

Прадукт раскладаецца на шэраг кампанентаў, кожны з якіх распрацаваны і пабудаваны асобна (называецца зборкамі). Кожны кампанент дастаўляецца кліенту, калі ён завершаны. Гэта дазваляе часткова выкарыстоўваць прадукт і дазваляе пазбегнуць працяглага часу распрацоўкі. Гэта таксама стварае вялікія першапачатковыя выдаткі на капітал, пазбягаючы наступнага доўгага чакання. Гэтая мадэль развіцця таксама дапамагае аслабіць траўматычны эфект ад увядзення цалкам новай сістэмы адразу.


У гэтай мадэлі ёсць некаторыя праблемы. Адзін з іх заключаецца ў тым, што кожная новая зборка павінна быць інтэгравана з папярэднімі зборкамі і любымі існуючымі сістэмамі. Задача раскладання прадукту на зборкі таксама не банальная. Калі зборкі занадта мала, і кожная зборка выраджаецца, гэта ператвараецца ў мадэль зборкі і выпраўлення. Аднак, калі зборкі занадта шмат, у кожнай зборцы мала карыснасці.

Перавагі дадатковай мадэлі

  • Хутка і рана генеруе працуючае праграмнае забеспячэнне на працягу жыццёвага цыкла праграмнага забеспячэння.
  • Больш гнуткі - менш затратны для змены сферы прымянення і патрабаванняў.
  • Прасцей тэставаць і адладжваць падчас меншай ітэрацыі.
  • Кіраваць рызыкай лягчэй, таму што падчас ітэрацыі ідэнтыфікуюцца рызыкоўныя часткі.
  • Кожная ітэрацыя - важны этап кіравання.

Недахопы дадатковай мадэлі

  • Кожная фаза ітэрацыі жорсткая і не перакрывае адна адну.
  • Могуць узнікнуць праблемы, звязаныя з архітэктурай сістэмы, бо не ўсе патрабаванні сабраны загадзя на працягу ўсяго жыццёвага цыкла праграмнага забеспячэння.

Калі выкарыстоўваць дадатковую мадэль

  • Такія мадэлі выкарыстоўваюцца там, дзе патрабаванні зразумелыя і могуць быць рэалізаваны паэтапна. З малюнка відаць, што патрабаванні ® дзеляцца на R1, R2 ……… .Rn і адпаведным чынам дастаўляюцца.
  • У асноўным такая мадэль выкарыстоўваецца ў вэб-праграмах і кампаніях, заснаваных на прадуктах.


Спрытная мадэль

Рухомая мадэль - гэта спалучэнне ітэрацыйнай і паступовай мадэляў шляхам разбіцця прадукту на кампаненты, дзе ў кожным цыкле або ітэрацыі пастаўляецца рабочая мадэль кампанента.

Мадэль выпускае бягучыя выпускі (паўторныя), кожны раз дадаючы невялікія змены да папярэдняга выпуску (ітэрацыйныя). Падчас кожнай ітэрацыі, калі выраб будуецца, яго таксама правяраюць, каб гарантаваць, што ў канцы ітэрацыі прадукт можна адгружаць.

Мадэль Agile падкрэслівае супрацоўніцтва, бо кліенты, распрацоўшчыкі і тэсціроўшчыкі працуюць разам на працягу ўсяго праекта.


Перавагай мадэлі Agile з'яўляецца тое, што яна хутка дае працуючы прадукт і лічыцца вельмі рэалістычным падыходам да распрацоўкі.

Адзін недахоп гэтай мадэлі заключаецца ў тым, што, паколькі гэта ў значнай ступені залежыць ад узаемадзеяння з кліентамі, праект можа пайсці не ў той бок, калі кліент не ведае, якія патрабаванні альбо кірунак ён хоча пайсці.



V Мадэль

V Model - удасканаленая версія класічнай мадэлі вадаспаду, дзякуючы якой кожны ўзровень жыццёвага цыкла распрацоўкі правяраецца перад пераходам на наступны ўзровень. З гэтай мадэллю тэсціраванне праграмнага забеспячэння відавочна пачынаецца з самага пачатку, гэта значыць, як толькі будуць напісаны патрабаванні.

Тут пад тэставаннем мы разумеем праверку з дапамогай аглядаў і праверак, гэта значыць статычнага тэсціравання. Гэта дапамагае ідэнтыфікаваць памылкі вельмі рана ў жыццёвым цыкле і мінімізуе патэнцыйныя дэфекты, якія з'явяцца ў кодзе пазней у жыццёвым цыкле.


Кожны ўзровень жыццёвага цыкла распрацоўкі мае адпаведны план выпрабаванняў. г.зн. па меры прапрацоўкі кожнай фазы распрацоўваецца план выпрабаванняў для падрыхтоўкі да выпрабаванняў прадуктаў гэтай фазы. Распрацоўваючы планы выпрабаванняў, мы можам таксама вызначыць чаканыя вынікі тэсціравання прадуктаў для гэтага ўзроўню, а таксама вызначыць крытэрыі ўваходу і выхаду для кожнага ўзроўню.

Як і Вадаспад, кожны этап пачынаецца толькі пасля заканчэння папярэдняга. Гэтая мадэль карысная, калі няма невядомых патрабаванняў, бо вярнуцца і ўнесці змены ўсё яшчэ складана.

V мадэль - перавагі

  • Кожная фаза мае пэўныя вынікі.
  • Больш высокія шанцы на поспех у параўнанні з мадэллю вадаспада дзякуючы распрацоўцы планаў выпрабаванняў на ранніх этапах жыццёвага цыкла.
  • Занепакоенасць часам у параўнанні з мадэллю вадаспада малая, альбо нават можна сказаць на 50% менш.
  • Добра працуе для невялікіх праектаў, дзе патрабаванні лёгка зразумець.
  • Карыснасць рэсурсаў высокая.

V мадэль - недахопы

  • Даволі жорсткая, як мадэль вадаспаду.
  • Мала гнуткасці і рэгулявання аб'ёму складана і дорага.
  • Праграмнае забеспячэнне распрацоўваецца на этапе рэалізацыі, таму раннія прататыпы праграмнага забеспячэння не вырабляюцца.
  • V Model не дае дакладнага шляху для праблем, выяўленых на этапах тэставання.

Калі выкарыстоўваць V-мадэль

  • Згодна з маімі ведамі, я асабіста думаю / адчуваю, дзе час і кошт з'яўляюцца абмежаваннем праекта, тады мы можам выкарыстоўваць такія мадэлі для хуткай і эканамічна эфектыўнай дастаўкі.
  • У параўнанні з мадэллю вадаспаду, V мадэль больш-менш аднолькавая, але актыўнасць выпрабаванняў пачынаецца вельмі рана, што прыводзіць да меншага часу і кошту праекта.


Мадэль вадаспаду

Мадэль вадаспаду - самая старажытная і простая з структураваных методык SDLC. Ёсць строгія этапы, і кожны этап трэба выканаць першым, перш чым пераходзіць да наступнага этапу. Вяртання назад няма.

Кожная фаза абапіраецца на інфармацыю з папярэдняй стадыі і мае свой уласны план праекта.

Вадаспад лёгка зразумець і кіраваць ім проста. Аднак, як правіла, гэта схільна да затрымак, бо кожны этап неабходна перагледзець і цалкам падпісаць перад пачаткам наступнага этапу.

Акрамя таго, паколькі пасля завяршэння этапу мала месца для перагляду, праблемы не могуць быць выпраўлены, пакуль вы не дойдзеце да этапу тэхнічнага абслугоўвання.

Гэтая мадэль працуе лепш за ўсё, калі вядомыя ўсе патрабаванні і не патрабуецца гнуткасць, а праект мае фіксаваны графік.

Перавагі мадэлі вадаспаду

  • Кожны этап мае пэўныя вынікі і працэс разгляду.
  • Фазы апрацоўваюцца і завяршаюцца адна за адной.
  • Добра працуе для невялікіх праектаў, дзе патрабаванні вельмі добра зразумелыя.
  • Гэта ўзмацняе паняцці 'вызначыць перад распрацоўкай' і 'распрацаваць перад кодам'.

Недахопы мадэлі вадаспаду

  • Рэгуляванне аб'ёму на працягу жыццёвага цыкла можа забіць праект
  • Ні адно рабочае праграмнае забеспячэнне не вырабляецца да позняга перыяду жыццёвага цыкла.
  • Вялікая колькасць рызык і нявызначанасці.
  • Дрэнная мадэль для складаных і аб'ектна-арыентаваных праектаў.
  • Дрэнная мадэль для працяглых і бягучых праектаў.
  • Дрэнная мадэль, дзе патрабаванні маюць умераны і высокі рызыка змянення.

Калі выкарыстоўваць мадэль вадаспаду

  • Такая мадэль шырока выкарыстоўваецца там, дзе патрабаванні зразумелыя і не будзе ніякіх змен у часе распрацоўкі. Мы можам знайсці такія сцэнары ў абаронных праектах, дзе патрабаванні будуць зразумелыя, бо перад тым, як напісаць патрабаванні, яны будуць добра аналізаваць.
  • Мы таксама можам назваць такую ​​мадэль жыццёвага цыкла для міграцыйных праектаў, дзе патрабаванні будуць аднолькавымі, толькі платформа альбо мовы могуць мяняцца / мяняцца.
  • Таксама можна выкарыстоўваць для праектаў, дзе спонсар сам будзе займацца тэставаннем, бо да завяршэння кадавання мы не будзем прадастаўляць праект.