E-ITSPEA 11: Arendus- ja ärimudelid

From ICO wiki
Revision as of 15:32, 5 September 2020 by Kaido.kikkas (talk | contribs)
Jump to navigationJump to search

Tagasi kursuse esilehele



Sissejuhatuseks

Tänases teemas on koos kaks väga suurt valdkonda, seega saab siit vaid üsna üldise ülevaate ja loodetavasti tõuke ise edasi uurida. Arendusmudelite ja tarkvaratehnika teemadest ei pääse mööda ükski tarkvaraarendaja, tänapäevane võrguäri aga paneb suuremat rõhku ka tarkvara ärimudelites orienteerumisele (dotcom'ide buum sajandivahetusel vaibus suures osas just nimelt seetõttu, et mõnd iseenesest huvitavat lahendust ei õnnestunud teenima panna). Mõlemast teemast aga tuleb igal juhul juttu ka edaspidi, siis aga juba eraldi kursustena.

Huvilistele võib edasiuurimiseks soovitada ka Inga Petuhhovi poolt läbiviidava Tallinna Ülikooli tarkvaratehnika kursuse materjale. Lisaks soovitaks "eelsoojenduseks" lugeda ka Paul Grahami 2003. aastal ilmunud esseed Hackers & Painters.

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 ühe 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.

Sammsammuline 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.

Kordustega ehk iteratiivne mudel

Skeem Wikimedia Commonsis

Sarnaselt eelmisega on siin tegu samm-sammulise arendusega (mõnel juhul kombineeritaksegi neid kaht mudelit, samuti kasutatakse kordustega lähenemist ka agiilses arenduses). Iga kordusega läbitakse kogu tegevusteahel planeerimisest testimise ja hindamiseni, iga taktiga kaasajastatakse ka dokumentatsiooni ning tulemusi kajastatakse vastavas dokumendis (project control list). Selle meetodi eeliseks on pidev koostöö sihtgrupiga ning regulaarse tagasiside kogumine, mida kasutakse järgmise takti ettevalmistamisel. Vajaduse korral on võimalik ka kogu takti "nullimine" ja alustamine mingist varasemast punktist. Samas on see mudel iga takti osas üsna jäik ning ei sobi olukordades, kus nõuded võivad takti käigus muutuda.

Spiraalmudel

Skeem Wikimedia Commonsis (NB! see on mõne hinnangu järgi ebatäpne)

Selle mudeli puhul kasutatakse samuti tegevuste kordust, kuid eri tasemetel (keskelt väljapoole liikudes, iga keerd tähistab uut prototüüpi). Eri autorid kasutavad sektorite puhul eri arve ja nimetusi (näiteks mudeli autor Barry Boehm kasutab nelja jaotust - eesmärgid, riskihaldus, arendus/valideerimine ja planeerimine, mõned teised aga kasutatavad sektoritena arendustsükli etappe analüüsist hoolduseni, näiteks planeerimine, analüüs, hindamine ja arendus). Selle mudeli eripäraks on riskide hindamine ja maandamine iga korduse/keeru (prototüübi) juures, mis aitab tagada kvaliteeti (ja prototüüpide näol jõuab tarkvara kliendini varajases staadiumis), kuid võib olla keerukas ja ressursimahukas - seetõttu peetakse seda mudelit sobivaks suuremahuliste projektide jaoks.

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.

Väledad ehk agiilsed mudelid

2001. aastal kohtusid Utah's 17 tarkvaraarendajat ning andsid välja "Agiilse manifesti", milles väljendati rida tõekspidamisi:

  • inimesed ja koostöö on olulisemad kui protsessid ja töövahendid (mõeldakse just reaalset koosviibimist ja koos programmeerimist)
  • töötav tarkvara on olulisem kui põhjalik dokumentatsioon
  • koostöö kliendiga on olulisem kui lepingutingimused (mõeldud on vajadust kaasata klient kogu protsessi, mitte vaid "telli ja maksa" stiilis)
  • muutustega kaasaminek on olulisem kui plaani järgimine

Kujunes rida erinevaid meetodeid ja mudeleid nagu

  • Ekstreemprogrammeerimine (extreme programming, XP) - rõhuasetus kiiretel väljalasetel, koodikontrollil (kasutakse palju ka paaristööd) ja testimisel
  • Funktsioonipõhine arendus (feature-driven development, FDD) - lähtutakse kliendi vaatest, järkjärgulise funktsionaalsuste lisamisega.
  • Scrum
  • Kanban
  • Scrumban (Scrumi ja Kanbani põhjal loodud hübriidmudel)
  • Lean
  • ...

Näitena võime lühidalt vaadelda üht levinumat - Scrumi. Scrumi puhul on projektis kolm põhirolli:

  • toote omanik (product owner) - esindab "kliendi häält" ning suunab projektimeeskonda soovitud suunas, samuti tegeleb kliendipoolse dokumentatsiooniga.
  • Scrum Master - täidab moderaatori rolli, jälgib Scrumi protsessidest kinnipidamist ning suhtleb aktiivselt nii toote omaniku kui arendusmeeskonnaga, aidates vajadusel lahendada töö käigus esinevaid probleeme.
  • arendusmeeskond - reeglina 3-9 liikmega, kes katavad ära kõik arendusprotsessi rollid (analüüs, disain, programmeerimine, testimine, dokumenteerimine...).

Tööprotsess käib nn sprintidena (kestusega tüüpiliselt 1 nädalast 1 kuuni), mis peaks lõppema konkreetse tulemusega (PSI, potentially shippable increment). Protsess dokumenteeritakse sprindilogis (sprint backlog), mis omakorda kuulub tootelogi (product backlog) koosseisu. Sprindi alguses korraldatakse planeerimiskoosolek, kus osalevad kõik asjaosalised ning pannakse paika sprindi jooksul eeldatavasti saavutatavad tulemused (need kantakse tootelogisse).

Sprindi kestel toimub iga päev 15-minutiline püstijalakoosolek (daily scrum), kus iga osaleja kannab lühidalt ette eelmisel päeval tehtu, selle päeva plaanid ja esinevad probleemid. Sprint lõpeb reeglina paaritunnise kokkuvõttega (sprint review), kus tehakse kokkuvõte saavutatust ja saavutamatajäetust ning esitletakse sprindi tulemusi (enamasti demo vormis, seega peab tulemus olema esitluskõlbulik) ning umbes sama pika tagasivaatega (sprint retrospective), mida juhib Scrum Master ja kus arutletakse üldisemalt, mis läks hästi ja mida järgmiseks korraks peaks parandama.

Agiilsete mudelite eeliseks peetakse tihedat suhtlust kliendiga, mis võimaldab kiireid täiendusi ja kohandumist nõudmistega. Miinuseks aga on peetud riski formaalse disaini ja dokumentatsiooni unarussejätmiseks, samuti on keeruline "suure pildi" tajumine projekti algfaasis (ning eriti hull on olukord siis, kui ka klient ei tea täpselt, mida tahab).

Vaba tarkvara arendusmudelid

Eespooltoodud arendusmudelid ja -meetodid on reeglina pärit kinnise lähtekoodiga tarkvara maailmast, ehkki neid saab eri määral rakendada ka avatud koodi tingimustes (spiraalmudel, iteratiivsed-inkrementaalsed ja RAD-mudelid; eriti lähedased on paindlikkust taotlevad agiilsed mudelid, olgugi et viimased kasutavad väikesi meeskondi vaba tarkvara juures sageli esinevate suurte kogukondade asemel). Ehk ainus selgelt ebasobiv on klassikaline kosemudel.

Vaba tarkvara projektide puhul on näha kaks suunda, mida Eric S. Raymond enda 1997. aasta essees nimetab "katedraaliks" (cathedral) ja "turuks" (bazaar). Katedraalitüüpi projektidel on enamasti olemas kindel kava, meeskond ja ajagraafik ning nad võivad kasutada mõnda eespoolkirjeldatud arendusmudelitest (isegi kosemudelit -seega ei eristu projekt suurtest ärivaraarendustest kuigivõrd millegi muu kui loodava tarkvara litsentsi poolest. Näitena võib tuua GNU projekti). Turutüüpi projektid on aga dünaamilised, liikuvate sihtmärkide ja muutuva kogukonnaga, moodustades enamiku vaba tarkvara projektidest.

Üks võimalik skeem Wikimedia Commonsist

Vaba tarkvara arendusprojektid võivad olla äärmiselt erineva iseloomu ja mahuga, ulatudes üksikutest utiliitidest (mida majutavad näiteks Github, Sourceforge, Savannah jmt) suurte rakenduste (näiteks LibreOffice), süsteemitarkvara (Linuxi tuum, GCC, Apache) ja terviklike operatsioonisüsteemideni (Linuxi distributsioonid nagu Ubuntu või Debian).

Projekt võib saada alguse eri viisidel, näiteks:

  1. Algataja teatab avalikult plaanist alustada projekti (foorumi, listi vms kaudu).
  2. Algataja avaldab senise eraviisilise töö tulemuse vaba tarkvara projektiga (näiteks avab Githubi projekti)-
  3. Kinnise tarkvaraprojekti omanik otsustab lähtekoodi avalikustada ja alustab vaba projekti (näiteks Microsoftil on terve rida Githubi projekte).
  4. Algataja või meeskond "lööb lahku" mõnest teisest vaba tarkvara projektist (enamasti põhimõtteliste lahkarvamuste tõttu) ja loob uue koodiharu (fork) eraldi projektina.

Vaba tarkvara projektide peamiste töövahenditena võib mainida

  • suhtluskanalid - e-post ja listid, IRC vmm reaalajasuhtluse viis, veeb, wikid ...
  • versioonihaldusega koodivaramu - CVS, Subversion, Git vmm
  • vea- ja ülesandehaldus - Bugzilla, Trac, Redmine vmm
  • testimis- ja silumisvahendid - GDB, Tinderbox jt
  • pakihaldus - RPM/Yum, DPKG/Apt jt

Parim meetod on puuduv meetod?

Tarkvaraarendajate hulgast võib leida ka neid, kelle jaoks kogu eespoolkirjeldatu on eluvõõras, pintsaklipslaste poolt pastakast väljaimetud jama. Sellist lähenemist on nimetatud ka "kauboiarenduseks" (cowboy coding) ehk "Code and fix"-lähenemiseks.

Päris huvitava kirjutise koos järgneva pika aruteluga leiab Greg Jorgenseni ajaveebist Typical Programmer. Samasse ooperisse arutelu leiab ka Slashdotist (2015. aasta lõpust).


Ärimudelid

Nagu on juba mainitud, sai tarkvara alguse suuresti mitteärilise nähtusena. Samas ei või väita, et see oli täiesti mitteäriline - esiteks tuli ka tollastel ülikoolidel ja uurimisasutustel arvutid ikkagi ettevõtetelt tellida (vajaminev tarkvara tuli kas arvutiga kaasa või kirjutati ise), teiseks tuli ilmselt ette ka allhanketöid konkreetsete tarkvaraprojektide elluviimisel. Ärivarale siirdumine sai järk-järgult alguse Unixi sulgumise ja hargnemisega 1970. aastatel, ent sümboolse stardipauguna võib vaadelda Bill Gatesi kuulsat "Avalikku kirja tarkvarahuvilistele" 1976. aastast.

Ärivaraliste peamiste ärimudelitena võiks mainida

  • Traditsiooniline omandvara - autor/omanik müüb oma tarkvara koopiahaaval, sarnaselt raamatute ja helikandjatega. Äriliselt ei eristu sedalaadi tarkvarafirma oluliselt mistahes muu mittemateriaalse kauba loojast (tänapäeval on ehk suurem osakaal paind- ja individuaaltööl kui seda võimaldaks füüsilise kauba tootmine). Omandvara erikujuna võib vaadelda ka jaosvara ja omand-vabavara (vt litsentside teemat). Eraldi tuleks mainida tendentsi pakkuda tarkvara läbi katusteenuse (hea näide on Steam).
  • Omandvara koos riistvaraga (tervikplatvorm) - selle suuna tuntuim esindaja tänapäeval on Apple. Ühelt poolt võimaldab see tootjal tagada probleemideta ühilduvus platvormi piires, teisalt aga tekitada kunstlikku defitsiiti.
  • Tarkvararent (application service providing, ASP) - tänases võrgupõhises maailmas saab tarkvara anda ka tähtajaliseks kasutamiseks ning mitmed tänased suuremad ärivaratootjad (sh Microsoft, Symantec jmt) ongi liikumas selles suunas.
  • Tarkvara kui teenus (software as a service, SaaS) - siin võib leida eri variante nagu kuutasulised (näiteks Adobe'i uuem tarkvara; piir tarkvararendiga on siin kohati hägune), reklaamipõhised (Google), mõeldav on ka kasutuskorra põhine lahendus (sarnaselt näiteks mobiilteenuste minuti- või sõnumiarvestusega).
  • Freemium - pakutakse nii tasuta toodet või teenust kui ka selle suuremate võimalustega tasulist versiooni (tegu võib olla mistahes mudeliga eelmistest).

Vaba tarkvara ärimudelitest võiks ära nimetada

  • Tervikliku tugisüsteemi pakkumine kindla kaubamärgi all - seda teeb Red Hat, edukaim äriklassi Linuxi pakkuja. Red Hati tarkvara ostja saab ligipääsu nende toetusmehhanismile, samuti on Red Hat Enterprise Linuxi kood läbinud põhjaliku testimise (firma kasutab "eesminejana" enda teist distrot, Fedora Linuxit - Fedora peal testitud ja heakskiidetud lahendused jõuavad mõni aeg hiljem RHEL-i). Samalaadseid lahendusi on ka Novellil (SUSE Linux Professional), IBMil (IBM LinuxONE), Oracle (Java) jpt.
  • Mitmiklitsentsimine - seda kasutab näiteks MySQL, mis on saadaval nii GPL-i kui ka omandvaralise litsentsi all; viimane võimaldab lisada täiendava tootetoetuse.
  • Hübriidne SaaS - vaba tarkvara võimaldab kombineerida tasulist pilveteenust tasuta allalaetavate lokaalsete tarkvarakomponentidega (näiteks teeb seda Dropbox).

Mõnevõrra ebakindlamatest võiks mainida

  • Annetustepõhine mudel - seda on aeg-ajalt kasutanud mitmed vaba tarkvara projektid.
  • Preemiamudel - "kes teeb selle-ja-selle valmis, saab N raha".
  • Ühisrahastusmudel - eelmisega võrreldes teistpidi: "kui saame N raha kokku, teeme selle-ja-selle valmis".
  • Reklaamimudel - seda on kasutanud Mozilla ja Canonical; reeglina aga toob see kaasa kasutajate protestid.

Lisaks võiks mainida ka täiendteenuseid nagu

  • Kirjastustegevus - vaba tarkvara teemalisi raamatuid on pikka aega edukalt kirjastanud O'Reilly.
  • Kaubamärgiga "nänni" müük - seda teevad edukalt mitmed firmad ja organisatsioonid, näiteks Canonical (Ubuntu) või Ungaris Linuxi-teemalisi T-särke tootev HelloTux.


Kokkuvõtteks

Mõlemat siin põgusalt puudutatud teemat tasub kindlasti edasi uurida. Kui arendusmudelite osas ei ole muutused nii kiired (tõenäoliselt on aga nii agiilsed kui vaba koodi mudelid edaspidigi kiirelt arenevad), siis ärimudelite osas on Interneti lai levik mitmed varasemad arusaamad üksjagu pea peale pööranud; tulevikus võib tõenäoliselt näha nii vabade mudelite jätkuvat levikut kui ka uute hübriidmudelite kujunemist.


Allikad

Üldist lugemist:

Üldine arendusmudel:

FLOSS mudel:

Uuri & kirjuta

Analüüsi ajaveebiartiklis üht tarkvara arendus- ja üht ärimudelit mõne konkreetse projekti näitel. Tagasi kursuse esilehele

Käesoleva materjali kasutamine ja levitamine on sätestatud Creative Commonsi Autorile viitamine + Jagamine samadel tingimustel 3.0 Eesti litsentsi (inglise keeles CC Attribution-ShareAlike ehk BY-SA) või selle uuema versiooniga.

Retrieved from "https://wiki.itcollege.ee/index.php?title=E-ITSPEA_11:_Arendus-_ja_ärimudelid&oldid=134219"