Arendus- ja ärimudelid: erinevus redaktsioonide vahel

Allikas: KakuWiki
Mine navigeerimisribaleMine otsikasti
13. rida: 13. rida:
1968. aastal avaldas hollandi arvutiteadlane Edgar Dijkstra artikli "Go To -lause on kahjulik", millest sai alguse [https://en.wikipedia.org/wiki/Structured_programming struktuurprogrammeerimine] - nõue kirjutada programmikood nii, et puuduksid "hüpped" koodis edasi-tagasi ning kood oleks selgelt struktureeritud (valiku- ja korduslausete ning alamprogrammide abil). 1980. aastal loodi [https://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_method SSADM], mida võib pidada üheks esimeseks kirjapandud arendusmudeliks (vt ka kosemudelit allpool). 90-ndatel muutus valitsevaks [https://en.wikipedia.org/wiki/Object-oriented_programming objektorienteeritud programmeerimine], mis pärineb küll juba 60-ndatest (Simula, Smalltalk, CLOS, Object Pascal). Selle põhimõteteks olid andmete (''data'') ja meetodite/koodi (''methods'') selge eraldatus, modulaarsus ning taaskasutus. Enamik allpoolkirjeldatud tänastest arendusmeetoditest pärinevad 90-ndatest ja 2000-ndatest aastatest.
1968. aastal avaldas hollandi arvutiteadlane Edgar Dijkstra artikli "Go To -lause on kahjulik", millest sai alguse [https://en.wikipedia.org/wiki/Structured_programming struktuurprogrammeerimine] - nõue kirjutada programmikood nii, et puuduksid "hüpped" koodis edasi-tagasi ning kood oleks selgelt struktureeritud (valiku- ja korduslausete ning alamprogrammide abil). 1980. aastal loodi [https://en.wikipedia.org/wiki/Structured_systems_analysis_and_design_method SSADM], mida võib pidada üheks esimeseks kirjapandud arendusmudeliks (vt ka kosemudelit allpool). 90-ndatel muutus valitsevaks [https://en.wikipedia.org/wiki/Object-oriented_programming objektorienteeritud programmeerimine], mis pärineb küll juba 60-ndatest (Simula, Smalltalk, CLOS, Object Pascal). Selle põhimõteteks olid andmete (''data'') ja meetodite/koodi (''methods'') selge eraldatus, modulaarsus ning taaskasutus. Enamik allpoolkirjeldatud tänastest arendusmeetoditest pärinevad 90-ndatest ja 2000-ndatest aastatest.


Märkus: täpsuse huvides tuleks programmeerimise põhiparadigmadest mainida ära ka [https://en.wikipedia.org/wiki/Logic_programming loogiline] (Prolog) ja [funktsionaalne] programmeerimine (Haskell jt). Nende käsitlemine jäägu aga juba programmeerimiskursustesse, kuna nad erinevad kõige levinumast imperatiivsest ehk käsupõhisest programmeerimisest üsna tublisti.
Märkus: täpsuse huvides tuleks programmeerimise põhiparadigmadest mainida ära ka [https://en.wikipedia.org/wiki/Logic_programming loogiline] (Prolog jt) ja [https://en.wikipedia.org/wiki/Functional_programming funktsionaalne] programmeerimine (Haskell jt). Nende käsitlemine jäägu aga juba programmeerimiskursustesse, kuna nad erinevad kõige levinumast imperatiivsest ehk käsupõhisest programmeerimisest üsna tublisti.


==== Kosemudel (''waterfall'') ====
==== Kosemudel (''waterfall'') ====

Redaktsioon: 4. november 2016, kell 09:59



...

Arendusmudelid

Kujunemine

Tarkvaraarenduse protsesside kirjeldamine ulatub tagasi 60-ndatesse, mil hakati kirjeldama suurettevõtete äriprotsesse. Hiljem kujunes mõiste "süsteemiarenduse elutsükkel" (SDLC, millest tarkvara moodustab üle alajaotuse (laiemas mõttes infosüsteem võib sisaldada ka riistvara). Lihtsamal kujul kujutab see protsessiringi planeerimisest valmissüsteemide haldamiseni (vt skeemi Wikimedia Commonsis).

1968. aastal avaldas hollandi arvutiteadlane Edgar Dijkstra artikli "Go To -lause on kahjulik", millest sai alguse struktuurprogrammeerimine - nõue kirjutada programmikood nii, et puuduksid "hüpped" koodis edasi-tagasi ning kood oleks selgelt struktureeritud (valiku- ja korduslausete ning alamprogrammide abil). 1980. aastal loodi SSADM, mida võib pidada üheks esimeseks kirjapandud arendusmudeliks (vt ka kosemudelit allpool). 90-ndatel muutus valitsevaks objektorienteeritud programmeerimine, mis pärineb küll juba 60-ndatest (Simula, Smalltalk, CLOS, Object Pascal). Selle põhimõteteks olid andmete (data) ja meetodite/koodi (methods) selge eraldatus, modulaarsus ning taaskasutus. Enamik allpoolkirjeldatud tänastest arendusmeetoditest pärinevad 90-ndatest ja 2000-ndatest aastatest.

Märkus: täpsuse huvides tuleks programmeerimise põhiparadigmadest mainida ära ka loogiline (Prolog jt) ja funktsionaalne programmeerimine (Haskell jt). Nende käsitlemine jäägu aga juba programmeerimiskursustesse, kuna nad erinevad kõige levinumast imperatiivsest ehk käsupõhisest programmeerimisest üsna tublisti.

Kosemudel (waterfall)

Skeem Wikimedia Commonsis

Tavaarusaama jaoks ilmselt kõige lihtsam viis, kus arendus koosneb selgetest etappidest (sarnaselt SDLC-ga) ning iga etapp viiakse lõpule, enne kui järgmise juurde asutakse:

Analüüs -> Disain -> Arendus -> Testimine -> Hooldus

Selle mudeli eeliseks on tema lihtsus ja ülevaatlikkus. Protsess on jäigalt paigas ning iga etapi puhul on selgelt määratud selle tulemus ja üleminek järgmisse. Kosemudel sobib hästi väiksemate ülesannete lahendamiseks, kus nõuded on algusest peale selged ega muutu töö käigus.

Miinuseid on aga üksjagu - kui midagi läks algfaasis (näiteks disainis) valesti ja see selgub alles testimisel, on tagasi minna keeruline, seetõttu on see mudel riskantne. Praktiline tulemus (tarkvara) valmib alles tsükli lõpupoole. Kõige selle tõttu ei sobi see mudel projektidele, mis on pikad ja keerukad, eriti aga juhtudel, kus nõuded võivad töö käigus muutuda.

V-mudel

Skeem Wikimedia Commonsis

Selle mudeli puhul moodustab kosemudeli sarnane protsess V-tähe või parabooli ning lisaks mööda põhiahelat kulgevale protsessile toimub infovahetus ka samal horisontaalil olevate sammude vahel. Arendusfaas asub V põhjas, vasaku haru moodustab analüüs/disain ja parempoolse testimine, nii et testimise eri etappide tulemused saavad mõjutada disainifaasi etappe. Projekti alguses kogutakse tagasisidet projekti lõppastmelt ehk lõpptarbijatelt ning kohandatakse nõudmisi selle järgi.

Mudeli plussideks on sarnaselt kosemudeliga lihtsus ja selgus, võimalik on ajavõit (testid kavandatakse juba varem, enne arendust). Vigade avastamise võimalus eri sammude juures on suurem ja need ei kandu edasi järgmistesse sammudesse. Sarnaselt kosemudeliga sobib see mudel väiksemale ja selgete nõudmistega projektile.

Miinuseks on nagu kosemudelil selle jäikus ning tarkvara valmimine protsessi lõpupoole (ehkki testimine toimub algusest peale, ei kasutata varajasi prototüüpe). Kuna testimine toimub kogu protsessis, peab testidokumentatsioon pidevalt kajastama kõiki tehtavaid muudatusi.

Märkus: V-mudelist on tehtud erinevaid edasiarendusi (mitme V mudelid), aga nende kajastamine jäägu juba tarkvaraarhitektuuri ainetesse.

Järkjärguline mudel (incremental)

Skeem Wikimedia Commonsis

Selle mudeli puhul kasutatakse järkjärgulist, korduvat arendust (prototüüpimist), milles iga kordus on omaette, kosemudelit järgiv protsess. Iga järgmise sammuga täiendatakse nõudeid ning lõpptulemus loetakse saavutatuks siis, kui kõik nõuded on rahuldatud.

Siin on oluliseks plussiks võimalus jõuda töötava tarkvarani juba üsna varajases staadiumis. Algse, väiksema väljalaske saab kliendini viia kohe alguses ning alustada selle testimist (ka testimine on algse väiksema mahu juures lihtsam ning vead tulevad kiiremini välja).

Miinuseks on seevastu kogu protsessi suurem kulukus (sama ülesande korduv lahendamine). Samuti on vaja head planeerimist ja "suure pildi" nägemist kohe alguses, et väljalaskeid planeerida ja kohe alguses õige suund valida.

RAD ehk kiirarenduse mudel (rapid application development)

Skeem Wikimedia Commonsis (üks võimalik lähenemine)

See on kogum kosemudelist eristuvaid mudeleid, kus pannakse vähem rõhku planeerimisele ja rohkem paindlikule realisatsioonile. Sageli töötatakse eri lõikude kallal paralleelselt. Eeliseks on suurem paindlikkus, modulaarsus (taaskasutuse võimalus, samas algusest peale toimuv kokkusobitamine tagab reeglina hea koostöö) ja kiirus. Samas vajavad RAD-meetodid kogenud ja võimekat, hästi kokkumängivat ja selge rollijaotusega arendusmeeskonda ning nad sobivad ülesannetele, mida saab "juppideks jagada" ja mis ei ole üleliia suuremahulised.

Teemad

...

Allikad

Üldine arendusmudel:

FLOSS mudel: