10 Pinaka-Kapaki-pakinabang na Mga Site para sa Mga Nag-develop ng Java
Pinagmulan: Tarun Telang Nasa ibaba ang isang listahan ng pinakamabisa at mapagkakatiwalaang mapagkukunan ng web tungkol sa teknolohiya ng Java. Maaari silang maging kapaki-pakinabang para sa parehong mga may karanasan na Java programmer at mga nagsisimula. Ginagamit ko ang mga mapagkukunang ito sa loob ng maraming taon upang mahanap ang pinakabagong impormasyon tungkol sa mga teknolohiya ng Java.
Ang mapagkukunan ay naglalaman ng impormasyon sa halos lahat ng kailangan mong malaman tungkol sa Java, kabilang ang mga balita, artikulo, blog, reference na materyales, mga opsyon sa karera, at impormasyong nauugnay sa mga proyekto ng Java. Inirerekomenda ko ang regular na pagbisita sa site na ito upang manatiling napapanahon sa pinakabagong balita tungkol sa platform ng Java.
Hindi mo magagawa nang wala ang mapagkukunang ito kung gusto mong i-download at i-install ang pinakabagong bersyon ng Java Development Kit. Naglalaman din ito ng mga detalyadong tagubilin kung paano patakbuhin ang mga file ng pag-install ng Java sa iba't ibang platform.
Ang seksyong ito ng site ng Oracle ay naglalaman ng reference na impormasyon sa Java SE API. Ang dokumentasyon ng HTML ay nabuo mula sa Java source code gamit ang JavaDoc tool.
Mayroong malaking koleksyon ng mga tutorial at reference na materyales sa Java programming language. Ang mga aralin ay makukuha rin bilang isang libro, The Java Tutorial, Sixth Edition (sa Ingles). Maaari mong sundan ang link na ito upang bilhin ito mula sa Amazon.
Naglalaman ang site ng mga pagsusulit sa pagsasanay at mga kapaki-pakinabang na mapagkukunan para sa pag-aaral ng mga paksa mula sa Java, mga database, Android, hanggang sa paghahanda ng sertipikasyon. Ito ay isang napakagandang lugar upang matuto ng Java sa pamamagitan ng mga praktikal na pagsasanay.
Dito mahahanap mo ang mga proyektong nauugnay sa Java EE, pati na rin ang mga proyektong dating naka-host sa Java.net. Ang site na ito ay naglalaman ng maraming iba't ibang mga link sa mga proyekto na may karagdagang impormasyon tungkol sa mga ito at impormasyon sa pakikipag-ugnayan na nauugnay sa mga proyektong ito.
Bisitahin ang site na ito para sundan ang mga talakayan, tanong at sagot tungkol sa mga teknolohiya at framework ng Java. Ang Javapedia.net ay kapaki-pakinabang para sa parehong may karanasan na Java at Java EE developer, gayundin para sa mga nagsisimula at mag-aaral na naghahanda para sa mga panayam.
Ang site ay naglalaman ng impormasyon tungkol sa mga pinakabagong teknolohiya sa Java Enterprise Edition. Ito ay isang lugar kung saan tinatalakay ng mga developer ng Java ang iba't ibang paksang nauugnay sa Java, Java EE, programming, software, at mga uso sa pag-unlad sa panig ng server. Ito ay isang napakalaking online na komunidad para sa mga enterprise architect at Java developer, kung saan makakahanap ka ng pang-araw-araw na balita, teknikal na talakayan, webinar at iba pang kapaki-pakinabang na impormasyon.
Ito ang lugar kung saan mahahanap mo ang pinakabagong Java software (mga laro, mobile at desktop application). Ito ay isang legal at ligtas na mapagkukunan para sa pag-install ng mga plugin ng Java. Hindi tulad ng maraming iba pang mga site, walang mga pop-up ad o kahina-hinalang mga file sa pag-install na hindi aktwal na nauugnay sa Java.
Dito makikita mo ang napapanahong impormasyon sa kung paano sinusuportahan ng Java ang inobasyon na nagpapagana sa ating digital na mundo. Ang site ay naglalaman ng isang koleksyon ng mga mapagkukunan sa platform ng Java para sa mga mag-aaral, mga hobbyist, mga developer at mga executive ng kumpanya ng IT. Bagama't makakahanap ka ng maraming katulad na mga site sa Internet na may mga link sa Java, karamihan sa mga ito ay luma na at nagpapakita ng impormasyon na may kaugnayan lamang bago ang Java 5. Mula noong Java 8, ang wika ay sumailalim sa malalaking pagbabago, na nangangailangan ng mga developer na kumuha ng bagong diskarte sa programming sa Java. Mabilis ding umuunlad ang wika, na may mga bagong bersyon ng Java na inilalabas tuwing anim na buwan.
7 Mga Modelo sa Pag-develop ng Software na Dapat Mong Malaman
Pinagmulan: DZone Ang ikot ng buhay ng pagbuo ng software ay ang proseso ng pagpaplano, pagdidisenyo, pagbuo, pagsubok at pag-deploy ng software sa pinakamababang posibleng gastos, mas mabuti sa pinakamaikling panahon. Upang makamit ang layuning ito, dapat piliin ng mga development team ang tamang modelo ng software development na nakakatugon sa mga kinakailangan ng proyekto at sa mga inaasahan ng lahat ng stakeholder. Mayroong 7 modelo na dapat mong malaman, mula sa Waterfall hanggang V-Model hanggang Scrum. Tingnan natin ang bawat isa sa kanila.
1. Modelong Cascade (Talon)
Ang modelo ng talon ay itinuturing na isa sa mga unang pamamaraan ng pagbuo ng software. Mula sa pangalan ay malinaw na ang proseso ng pag-unlad na ito ay may kasamang linear na pag-unlad sa pagkakasunud-sunod: pagsusuri, disenyo, pag-unlad, pagsubok, pag-deploy at suporta. Ang bawat yugto ay malinaw na tinukoy ng mga tiyak na resulta. Ang modelo ng talon ay sunud-sunod, ibig sabihin ay hindi magsisimula ang susunod na yugto hanggang sa makumpleto ang kasalukuyang yugto. Ang isang yugto ay itinuturing na kumpleto kapag ang layunin ay nakamit at may sumang-ayon na magpatuloy sa paggawa sa proyekto. Walang kakayahang umangkop sa modelong ito—hindi ka maaaring lumaktaw, bumalik, o magbago ng mga hakbang. Bilang resulta, ang proseso ng pag-unlad ay maaaring hindi kinakailangang kumplikado at magastos. Ang kakulangan ng kakayahang umangkop ay ginagawang mas mahal at labor intensive ang modelong ito kumpara sa iba pang mga modelo. Kung ang mga kinakailangan ay hindi malinaw o hindi nauunawaan, kung gayon ang paggamit ng modelong ito ay lubhang mapanganib. Bukod pa rito, ang modelong ito ay hindi perpekto para sa pangmatagalan, kumplikado o patuloy na mga proyekto kung saan kinakailangan ang higit na kakayahang umangkop. Bagama't kapansin-pansin at kapansin-pansin ang mga pagkukulang ng modelo, maaari itong maging kapaki-pakinabang para sa maliliit, isang-isang proyekto na may limitadong mga kinakailangan at maiikling deadline dahil simple at mabilis itong i-set up. Gayunpaman, dapat tiyakin ng koponan na ang lahat ng mga kinakailangan ay malinaw na tinukoy, hindi malabo at hindi maaaring magbago sa hinaharap. Ang modelo ng Waterfall ay hindi na pabor habang tinatanggap ng mga IT team ang mas maliksi na pag-develop ng software na nagbibigay-daan para sa patuloy na mga pagpapabuti.
2. V-modelo
Pinapalawak ng V-model, o modelo ng pag-apruba at pag-verify, ang modelo ng waterfall sa pamamagitan ng pagdaragdag ng plano sa pagsubok. Sa halip na lumipat nang linear pababa sa mga yugto ng pagbuo ng software, ang V-modelo ay lumilipat pababa sa coding stage, pagkatapos ay lumiliko at nagsimulang umakyat sa mga yugto ng pagsubok, na bumubuo ng isang V-shape. Ang bawat yugto ng pag-unlad ay tumutugma sa isang partikular na aktibidad sa pagsubok. Nagbibigay-daan ito sa team na makahanap ng mga bug sa mga detalye, code, at arkitektura nang maaga sa proyekto. Ang pagdaragdag ng plano sa pagsubok ay nagbibigay sa V-modelo ng mas magandang pagkakataong magtagumpay kaysa sa waterfall model. Gayunpaman, ang V-modelo ay nananatiling linear, na ginagawang hindi nababaluktot. Tulad ng sa modelo ng talon, ang koponan ay maaaring magsimula sa susunod na yugto lamang pagkatapos makumpleto ang nakaraang yugto. Ginagawa nitong mahirap, magastos at nakakaubos ng oras ang mga pagbabago. Kaya, ang modelong ito ay pinakaangkop para sa mga maiikling proyekto na may nakapirming, mahusay na tinukoy at dokumentado na mga kinakailangan, ngunit hindi perpekto para sa pangmatagalan, kumplikado o patuloy na mga proyekto.
3. Iterative (incremental) na modelo
Tulad ng ibang mga modelo ng pag-develop ng software, ang umuulit (incremental) na modelo ay idinisenyo upang malampasan ang ilan sa mga disadvantage ng modelo ng waterfall. Nagsisimula din ito sa pagpaplano at nagtatapos sa pag-deploy. Ngunit hindi tulad ng modelo ng waterfall, ang modelong ito ay nagsasangkot ng mga paulit-ulit na cycle sa buong proseso. Ang mga loop na ito ay maaaring umuulit (paulit-ulit) o incremental (step-by-step). Ang proseso ng pagbuo ay nagsisimula sa isang maliit na hanay ng mga kinakailangan, at ang bawat cycle sa loob nito ay sinamahan ng isang bagong hanay ng mga kinakailangan. Ang umuulit na katangian ng modelong ito ay nagpapahintulot sa software na umunlad at lumago habang ang maliliit na pagbabago ay maaaring gawin sa buong proseso. Nangyayari ito dahil nabuo ang bagong pag-ulit sa nauna. Maaaring gumawa ng mga pagbabago ang mga developer batay sa karanasan mula sa mga nakaraang cycle. Dahil ang lahat ng mga kinakailangan ay hindi inilatag sa simula ng proyekto at maraming mga pagbabago ang ginawa sa daan, ang trabaho ay maaaring magsimula nang mabilis. Gayunpaman, ang mga mapagkukunan ay maaaring mabilis na maubos dahil ang proseso ay madalas na paulit-ulit, hindi banggitin ang pamamahala ay nagiging mas kumplikado. Bagama't pinapayagan ng modelo ang ilang pagbabago, binubuo pa rin ito ng malinaw na tinukoy na mga proseso, na kung minsan ay humahantong sa kawalan ng kakayahang umangkop. Ang halaga ng paggawa ng mga pagbabago ay mas mababa kaysa sa waterfall at mga modelo ng V, ngunit ang modelong ito ay hindi perpekto para sa mga proyekto kung saan maaaring magbago ang mga kinakailangan sa panahon ng pag-ulit. Ang umuulit na modelo ay lumilikha ng higit pang mga panganib dahil sa mga madalas na pagbabago, hindi alam na mga gastos at mga kinakailangan sa mapagkukunan, at hindi tiyak na mga timeline.
4. Prototyping model
Nakatuon ang modelo ng prototyping sa pagpapabuti ng pag-unawa ng development team sa mga gusto at pangangailangan ng kliyente sa pamamagitan ng paggawa ng mga prototype. Sa pamamagitan ng paglikha ng isang maliit na gumaganang kopya ng nais na programa, ang mga hindi pagkakaunawaan ay maaaring maalis bago magsimula ang buong pag-unlad. Ang prototype ay binuo, sinubukan at tinatapos na isinasaalang-alang ang mga kagustuhan at komento ng customer. Kapag natanggap na ang prototype, sisimulan ng koponan ang pagbuo ng panghuling produkto. Ang isang modelo ng prototyping ay maaaring makabuluhang bawasan ang bilang ng mga pag-ulit. Makakatipid ito ng oras at pinapataas ang mga pagkakataon ng kasiyahan ng customer. Gayunpaman, kailangan mong isaalang-alang ang oras na ginugugol ng isang developer sa pagbuo ng mga prototype. Kung ang customer ay nangangailangan ng maraming pagbabago, madalas na nagbabago ang kanyang isip, o gumagawa ng hindi makatotohanang mga kahilingan, ang pagbuo ng isang prototype ay maaaring mabilis na maging kumplikado. Para sa kadahilanang ito, pinakamahusay na limitahan ang bilang ng mga pag-ulit na pinapayagan bago tanggapin ang prototype. Kapag ang panghuling prototype ay nasa pagbuo, walang karagdagang mga kinakailangan o pagbabago ang maaaring gawin sa plano. Ito ay isang makabuluhang disbentaha ng modelo ng prototyping.
5. Spiral na modelo
Ang spiral model ay nakatuon sa pagtatasa ng panganib. Bilang resulta, ang anumang pangkat na gustong gamitin ang modelong ito ay dapat na mayroong mga espesyalista na may kaalaman at kasanayan sa isang partikular na lugar. Ang modelo ay binubuo ng apat na yugto: pagpaplano, pagtatasa ng panganib, pag-unlad at pagsusuri. Ang bilang ng mga pagliko sa spiral ay depende sa partikular na proyekto at sa mga kinakailangan ng manager. Sa karaniwan, ang pagbuo ng software gamit ang modelong ito ay tumatagal ng 6 na buwan. Pinagsasama ng Spiral model ang mga feature ng waterfall model at prototyping sa pamamagitan ng pagbibigay-diin sa disenyo, kabilang ang prototyping (sa yugto ng disenyo), at sa pamamagitan ng pagsunod sa mga hakbang na katulad ng sa Waterfall model. Ang tuluy-tuloy at umuulit na pag-unlad ay nagbibigay-daan sa mga developer na gumawa ng mga pagbabago at magdagdag ng mga bagong feature. Bilang karagdagan, ang pag-unlad ay sistematiko, na nagpapadali sa proseso. Ang customer ay kasangkot sa pagsusuri ng bawat yugto ng cycle, na maaaring maging mabigat para sa proseso ng pag-unlad kung walang patuloy na komunikasyon sa customer. Dahil hindi tinukoy ang bilang ng mga pag-ikot o pag-ulit, may panganib ng labis na badyet at hindi nasagot na mga deadline. Samakatuwid, ang paglikha ng isang tapos na produkto ay madalas na nangangailangan ng maraming gastos at oras.
Flexible na pamamaraan (Agile)
Ang Agile ay isang pamamaraan batay sa 12 prinsipyong nakabalangkas sa Agile Manifesto . Ito ay higit pa sa isang mindset kaysa sa isang hanay ng mga mahigpit na protocol. Ang Agile method ay idinisenyo upang bumuo ng software nang mas mahusay kaysa sa paggamit ng mga nakaraang modelo, kabilang ang waterfall model. Ang kakanyahan ng maliksi na modelo ay ang pagtuon sa pakikipagtulungan, komunikasyon at patuloy na pagbabago. Mayroong ilang mga opsyon para sa Agile development. Nakatuon silang lahat sa pagtutulungan ng magkakasama, cross-functional na pakikipagtulungan, umuulit na pag-unlad, at maagang feedback ng customer. Ang pagsubok, feedback, at mga pagbabago ay nagbibigay-daan sa mga koponan na bumuo at maglabas ng mas mahusay na software. Tingnan natin ang 2 Agile models.
6. Modelo ng scrum
Ang modelo ng Scrum ay ang pinakasikat na modelo ng Agile. Ang mga pag-uulit ng pagbuo nito ay kilala bilang mga sprint. Sa mga 1-4 na linggong sprint na ito, sinusuri ng mga team ang nakaraang sprint, magdagdag ng mga bagong feature, at planuhin ang susunod na sprint. Hindi pinapayagan ang mga pagbabago pagkatapos matukoy ang mga aktibidad sa sprint. Pagkatapos ng bawat sprint, magdaragdag ng mga bagong feature/elemento na iko-code at susubukan sa susunod na sprint. Nagpapatuloy ito hanggang sa maidagdag ang lahat ng feature at maituturing na handa na ang proyekto para sa release. Ang pinataas na pakikipagtulungan sa pagitan ng mga cross-functional na koponan, at sa pagitan ng organisasyon at ng customer, ay nakakabawas sa mga hindi pagkakaunawaan at mga pagkakamali na kadalasang nagmumula sa hindi magandang komunikasyon. Bukod pa rito, binabawasan ng mga karagdagang hakbang ang oras sa market. Binabawasan ng pinahusay na komunikasyon ang oras na ginugol sa pag-troubleshoot ng mga error at pinatataas ang posibilidad na masisiyahan ang end user sa produkto. Gayunpaman, ang ganitong pakikipagtulungan ay nangangailangan ng makabuluhang partisipasyon mula sa kliyente sa proseso ng trabaho. Kailangan mo ring isaalang-alang na kung ang customer ay nangangailangan ng pagdaragdag ng masyadong maraming mga function, ang deadline ng proyekto ay maaaring maantala.
7. modelo ng Kanban
Hindi tulad ng ibang mga modelo, ang Kanban ay walang natatanging mga pag-ulit. Kapag ang isang koponan ay nagpaplano ng mga pag-ulit, ang mga ito ay hindi kapani-paniwalang maiikling mga sprint, kung minsan ay kasing-ikli ng isang araw. Upang biswal na ipahiwatig ang katayuan ng proyekto at iba pang mga detalye, ginagamit ang isang board na may mga tala sa anyo ng mga sticker (sticker). Binibigyang-daan ng visualization na ito ang team na tumuon sa pinakamahalagang feature sa development sa ngayon. Bukod pa rito, binibigyang-diin ng Kanban board na may puwang para sa patuloy na pagpapabuti ng feature. Bagama't ang paraan ng sticky note ay maaaring makatulong sa pag-udyok sa isang team na tumuon sa mahalagang gawain, ito ay isang hindi magandang paraan upang tukuyin at mapanatili ang mga timeline. Dahil dito, napakahirap magplano ng mga pangmatagalang proyekto. Dahil walang nakatakdang yugto ng pagpaplano, ang mga pagbabago ay maaaring gawin anumang oras. Isa sa mga karaniwang disadvantage ng Kanban ay ang kakulangan ng time frame. Maaaring lumala ang problemang ito kung patuloy na ginagawa ang mga pagbabago.
Transition to Agile
Ang bawat isa sa mga modelong ito ay nilikha upang mapabuti ang pagbuo ng software at proseso ng paghahatid. Ang anumang modelo ng pag-unlad ay maaaring gumana nang maayos para sa mga partikular na uri ng mga proyekto. Gayunpaman, ang mga mas lumang manu-manong modelo, tulad ng modelo ng cascade, ay mabilis na nagiging isang bagay ng nakaraan. Ang mga IT team at kumpanya sa pangkalahatan ay dapat kumilos nang mas mabilis at mas mahusay kapag gumagawa ng software, nakakatugon sa mga pangangailangan ng customer at nakikisabay sa mga kakumpitensya. Ang isang mas mabilis, mas nauulit at mas ligtas na proseso ng pagbuo ng software ay batay sa automation. At dahil ang antas ng automation at bilis ay hindi matamo para sa maraming mga modelo, nagiging mas popular ang Agile methodology.
Mayroong 7 modelo na dapat mong malaman, mula sa Waterfall hanggang V-Model hanggang Scrum. Tingnan natin ang bawat isa sa kanila.
Ang modelo ng talon ay itinuturing na isa sa mga unang pamamaraan ng pagbuo ng software. Mula sa pangalan ay malinaw na ang proseso ng pag-unlad na ito ay may kasamang linear na pag-unlad sa pagkakasunud-sunod: pagsusuri, disenyo, pag-unlad, pagsubok, pag-deploy at suporta. Ang bawat yugto ay malinaw na tinukoy ng mga tiyak na resulta. Ang modelo ng talon ay sunud-sunod, ibig sabihin ay hindi magsisimula ang susunod na yugto hanggang sa makumpleto ang kasalukuyang yugto. Ang isang yugto ay itinuturing na kumpleto kapag ang layunin ay nakamit at may sumang-ayon na magpatuloy sa paggawa sa proyekto. Walang kakayahang umangkop sa modelong ito—hindi ka maaaring lumaktaw, bumalik, o magbago ng mga hakbang. Bilang resulta, ang proseso ng pag-unlad ay maaaring hindi kinakailangang kumplikado at magastos. Ang kakulangan ng kakayahang umangkop ay ginagawang mas mahal at labor intensive ang modelong ito kumpara sa iba pang mga modelo. Kung ang mga kinakailangan ay hindi malinaw o hindi nauunawaan, kung gayon ang paggamit ng modelong ito ay lubhang mapanganib. Bukod pa rito, ang modelong ito ay hindi perpekto para sa pangmatagalan, kumplikado o patuloy na mga proyekto kung saan kinakailangan ang higit na kakayahang umangkop. Bagama't kapansin-pansin at kapansin-pansin ang mga pagkukulang ng modelo, maaari itong maging kapaki-pakinabang para sa maliliit, isang-isang proyekto na may limitadong mga kinakailangan at maiikling deadline dahil simple at mabilis itong i-set up. Gayunpaman, dapat tiyakin ng koponan na ang lahat ng mga kinakailangan ay malinaw na tinukoy, hindi malabo at hindi maaaring magbago sa hinaharap. Ang modelo ng Waterfall ay hindi na pabor habang tinatanggap ng mga IT team ang mas maliksi na pag-develop ng software na nagbibigay-daan para sa patuloy na mga pagpapabuti.
Pinapalawak ng V-model, o modelo ng pag-apruba at pag-verify, ang modelo ng waterfall sa pamamagitan ng pagdaragdag ng plano sa pagsubok. Sa halip na lumipat nang linear pababa sa mga yugto ng pagbuo ng software, ang V-modelo ay lumilipat pababa sa coding stage, pagkatapos ay lumiliko at nagsimulang umakyat sa mga yugto ng pagsubok, na bumubuo ng isang V-shape. Ang bawat yugto ng pag-unlad ay tumutugma sa isang partikular na aktibidad sa pagsubok. Nagbibigay-daan ito sa team na makahanap ng mga bug sa mga detalye, code, at arkitektura nang maaga sa proyekto. Ang pagdaragdag ng plano sa pagsubok ay nagbibigay sa V-modelo ng mas magandang pagkakataong magtagumpay kaysa sa waterfall model. Gayunpaman, ang V-modelo ay nananatiling linear, na ginagawang hindi nababaluktot. Tulad ng sa modelo ng talon, ang koponan ay maaaring magsimula sa susunod na yugto lamang pagkatapos makumpleto ang nakaraang yugto. Ginagawa nitong mahirap, magastos at nakakaubos ng oras ang mga pagbabago. Kaya, ang modelong ito ay pinakaangkop para sa mga maiikling proyekto na may nakapirming, mahusay na tinukoy at dokumentado na mga kinakailangan, ngunit hindi perpekto para sa pangmatagalan, kumplikado o patuloy na mga proyekto.
Tulad ng ibang mga modelo ng pag-develop ng software, ang umuulit (incremental) na modelo ay idinisenyo upang malampasan ang ilan sa mga disadvantage ng modelo ng waterfall. Nagsisimula din ito sa pagpaplano at nagtatapos sa pag-deploy. Ngunit hindi tulad ng modelo ng waterfall, ang modelong ito ay nagsasangkot ng mga paulit-ulit na cycle sa buong proseso. Ang mga loop na ito ay maaaring umuulit (paulit-ulit) o incremental (step-by-step). Ang proseso ng pagbuo ay nagsisimula sa isang maliit na hanay ng mga kinakailangan, at ang bawat cycle sa loob nito ay sinamahan ng isang bagong hanay ng mga kinakailangan. Ang umuulit na katangian ng modelong ito ay nagpapahintulot sa software na umunlad at lumago habang ang maliliit na pagbabago ay maaaring gawin sa buong proseso. Nangyayari ito dahil nabuo ang bagong pag-ulit sa nauna. Maaaring gumawa ng mga pagbabago ang mga developer batay sa karanasan mula sa mga nakaraang cycle. Dahil ang lahat ng mga kinakailangan ay hindi inilatag sa simula ng proyekto at maraming mga pagbabago ang ginawa sa daan, ang trabaho ay maaaring magsimula nang mabilis. Gayunpaman, ang mga mapagkukunan ay maaaring mabilis na maubos dahil ang proseso ay madalas na paulit-ulit, hindi banggitin ang pamamahala ay nagiging mas kumplikado. Bagama't pinapayagan ng modelo ang ilang pagbabago, binubuo pa rin ito ng malinaw na tinukoy na mga proseso, na kung minsan ay humahantong sa kawalan ng kakayahang umangkop. Ang halaga ng paggawa ng mga pagbabago ay mas mababa kaysa sa waterfall at mga modelo ng V, ngunit ang modelong ito ay hindi perpekto para sa mga proyekto kung saan maaaring magbago ang mga kinakailangan sa panahon ng pag-ulit. Ang umuulit na modelo ay lumilikha ng higit pang mga panganib dahil sa mga madalas na pagbabago, hindi alam na mga gastos at mga kinakailangan sa mapagkukunan, at hindi tiyak na mga timeline.
Nakatuon ang modelo ng prototyping sa pagpapabuti ng pag-unawa ng development team sa mga gusto at pangangailangan ng kliyente sa pamamagitan ng paggawa ng mga prototype. Sa pamamagitan ng paglikha ng isang maliit na gumaganang kopya ng nais na programa, ang mga hindi pagkakaunawaan ay maaaring maalis bago magsimula ang buong pag-unlad. Ang prototype ay binuo, sinubukan at tinatapos na isinasaalang-alang ang mga kagustuhan at komento ng customer. Kapag natanggap na ang prototype, sisimulan ng koponan ang pagbuo ng panghuling produkto. Ang isang modelo ng prototyping ay maaaring makabuluhang bawasan ang bilang ng mga pag-ulit. Makakatipid ito ng oras at pinapataas ang mga pagkakataon ng kasiyahan ng customer. Gayunpaman, kailangan mong isaalang-alang ang oras na ginugugol ng isang developer sa pagbuo ng mga prototype. Kung ang customer ay nangangailangan ng maraming pagbabago, madalas na nagbabago ang kanyang isip, o gumagawa ng hindi makatotohanang mga kahilingan, ang pagbuo ng isang prototype ay maaaring mabilis na maging kumplikado. Para sa kadahilanang ito, pinakamahusay na limitahan ang bilang ng mga pag-ulit na pinapayagan bago tanggapin ang prototype. Kapag ang panghuling prototype ay nasa pagbuo, walang karagdagang mga kinakailangan o pagbabago ang maaaring gawin sa plano. Ito ay isang makabuluhang disbentaha ng modelo ng prototyping.
Ang spiral model ay nakatuon sa pagtatasa ng panganib. Bilang resulta, ang anumang pangkat na gustong gamitin ang modelong ito ay dapat na mayroong mga espesyalista na may kaalaman at kasanayan sa isang partikular na lugar. Ang modelo ay binubuo ng apat na yugto: pagpaplano, pagtatasa ng panganib, pag-unlad at pagsusuri. Ang bilang ng mga pagliko sa spiral ay depende sa partikular na proyekto at sa mga kinakailangan ng manager. Sa karaniwan, ang pagbuo ng software gamit ang modelong ito ay tumatagal ng 6 na buwan. Pinagsasama ng Spiral model ang mga feature ng waterfall model at prototyping sa pamamagitan ng pagbibigay-diin sa disenyo, kabilang ang prototyping (sa yugto ng disenyo), at sa pamamagitan ng pagsunod sa mga hakbang na katulad ng sa Waterfall model. Ang tuluy-tuloy at umuulit na pag-unlad ay nagbibigay-daan sa mga developer na gumawa ng mga pagbabago at magdagdag ng mga bagong feature. Bilang karagdagan, ang pag-unlad ay sistematiko, na nagpapadali sa proseso. Ang customer ay kasangkot sa pagsusuri ng bawat yugto ng cycle, na maaaring maging mabigat para sa proseso ng pag-unlad kung walang patuloy na komunikasyon sa customer. Dahil hindi tinukoy ang bilang ng mga pag-ikot o pag-ulit, may panganib ng labis na badyet at hindi nasagot na mga deadline. Samakatuwid, ang paglikha ng isang tapos na produkto ay madalas na nangangailangan ng maraming gastos at oras.
Ang modelo ng Scrum ay ang pinakasikat na modelo ng Agile. Ang mga pag-uulit ng pagbuo nito ay kilala bilang mga sprint. Sa mga 1-4 na linggong sprint na ito, sinusuri ng mga team ang nakaraang sprint, magdagdag ng mga bagong feature, at planuhin ang susunod na sprint. Hindi pinapayagan ang mga pagbabago pagkatapos matukoy ang mga aktibidad sa sprint. Pagkatapos ng bawat sprint, magdaragdag ng mga bagong feature/elemento na iko-code at susubukan sa susunod na sprint. Nagpapatuloy ito hanggang sa maidagdag ang lahat ng feature at maituturing na handa na ang proyekto para sa release. Ang pinataas na pakikipagtulungan sa pagitan ng mga cross-functional na koponan, at sa pagitan ng organisasyon at ng customer, ay nakakabawas sa mga hindi pagkakaunawaan at mga pagkakamali na kadalasang nagmumula sa hindi magandang komunikasyon. Bukod pa rito, binabawasan ng mga karagdagang hakbang ang oras sa market. Binabawasan ng pinahusay na komunikasyon ang oras na ginugol sa pag-troubleshoot ng mga error at pinatataas ang posibilidad na masisiyahan ang end user sa produkto. Gayunpaman, ang ganitong pakikipagtulungan ay nangangailangan ng makabuluhang partisipasyon mula sa kliyente sa proseso ng trabaho. Kailangan mo ring isaalang-alang na kung ang customer ay nangangailangan ng pagdaragdag ng masyadong maraming mga function, ang deadline ng proyekto ay maaaring maantala.
Hindi tulad ng ibang mga modelo, ang Kanban ay walang natatanging mga pag-ulit. Kapag ang isang koponan ay nagpaplano ng mga pag-ulit, ang mga ito ay hindi kapani-paniwalang maiikling mga sprint, kung minsan ay kasing-ikli ng isang araw. Upang biswal na ipahiwatig ang katayuan ng proyekto at iba pang mga detalye, ginagamit ang isang board na may mga tala sa anyo ng mga sticker (sticker). Binibigyang-daan ng visualization na ito ang team na tumuon sa pinakamahalagang feature sa development sa ngayon. Bukod pa rito, binibigyang-diin ng Kanban board na may puwang para sa patuloy na pagpapabuti ng feature. Bagama't ang paraan ng sticky note ay maaaring makatulong sa pag-udyok sa isang team na tumuon sa mahalagang gawain, ito ay isang hindi magandang paraan upang tukuyin at mapanatili ang mga timeline. Dahil dito, napakahirap magplano ng mga pangmatagalang proyekto. Dahil walang nakatakdang yugto ng pagpaplano, ang mga pagbabago ay maaaring gawin anumang oras. Isa sa mga karaniwang disadvantage ng Kanban ay ang kakulangan ng time frame. Maaaring lumala ang problemang ito kung patuloy na ginagawa ang mga pagbabago.
GO TO FULL VERSION