UNIVERZA V LJUBLJANI EKONOMSKA FAKULTETA
MAGISTRSKO DELO
DOLOČITEV KRITERIJEV SMISELNOSTI NADALJNJEGA INTERNEGA RAZVOJA PROGRAMSKE REŠITVE
Ljubljana, september 2016 VID JAGODIČ
IZJAVA O AVTORSTVU Podpisani Vid Jagodič, študent Ekonomske fakultete Univerze v Ljubljani, avtor predloženega dela z naslovom Določitev kriterijev smiselnosti nadaljnjega internega razvoja programske rešitve, pripravljenega v sodelovanju s svetovalcem prof. dr. Alešem Groznikom,
IZJAVLJAM 1. da sem predloženo delo pripravil samostojno; 2. da je tiskana oblika predloženega dela istovetna njegovi elektronski obliki; 3. da je besedilo predloženega dela jezikovno korektno in tehnično pripravljeno v skladu z Navodili za
izdelavo zaključnih nalog Ekonomske fakultete Univerze v Ljubljani, kar pomeni, da sem poskrbel, da so dela in mnenja drugih avtorjev oziroma avtoric, ki jih uporabljam oziroma navajam v besedilu, citirana oziroma povzeta v skladu z Navodili za izdelavo zaključnih nalog Ekonomske fakultete Univerze v Ljubljani;
4. da se zavedam, da je plagiatorstvo – predstavljanje tujih del (v pisni ali grafični obliki) kot mojih lastnih
– kaznivo po Kazenskem zakoniku Republike Slovenije; 5. da se zavedam posledic, ki bi jih na osnovi predloženega dela dokazano plagiatorstvo lahko predstavljalo
za moj status na Ekonomski fakulteti Univerze v Ljubljani v skladu z relevantnim pravilnikom; 6. da sem pridobil vsa potrebna dovoljenja za uporabo podatkov in avtorskih del v predloženem delu in jih v
njem jasno označil; 7. da sem pri pripravi predloženega dela ravnal v skladu z etičnimi načeli in, kjer je to potrebno, za raziskavo
pridobil soglasje etične komisije; 8. da soglašam, da se elektronska oblika predloženega dela uporabi za preverjanje podobnosti vsebine z
drugimi deli s programsko opremo za preverjanje podobnosti vsebine, ki je povezana s študijskim informacijskim sistemom članice;
9. da na Univerzo v Ljubljani neodplačno, neizključno, prostorsko in časovno neomejeno prenašam pravico
shranitve predloženega dela v elektronski obliki, pravico reproduciranja ter pravico dajanja predloženega dela na voljo javnosti na svetovnem spletu preko Repozitorija Univerze v Ljubljani;
10. da hkrati z objavo predloženega dela dovoljujem objavo svojih osebnih podatkov, ki so navedeni v njem
in v tej izjavi. V Ljubljani, dne 6. september 2016 Podpis študenta:__________________
i
KAZALO
UVOD ................................................................................................................................... 1
1 KLJUČNI KRITERIJI ZA OCENO PROGRAMSKE REŠITVE ......................... 3
2 KRITERIJI ZA OCENO KVALITETE PROGRAMSKE REŠITVE ................... 4
2.1 Kriteriji uporabnosti ................................................................................................ 4 2.1.1 Ocena izvedljivosti naloge ............................................................................... 4 2.1.2 Težave z uporabnostjo ..................................................................................... 5 2.1.3 Čas za izvedbo naloge ...................................................................................... 5 2.1.4 Stopnja zadovoljstva ob izvedbi naloge ........................................................... 5 2.1.5 Stopnja zadovoljstva po testiranju uporabnosti ............................................... 5 2.1.6 Napake uporabe................................................................................................ 6 2.1.7 Pričakovanje uporabnika .................................................................................. 6 2.1.8 Število klikov ................................................................................................... 6 2.1.9 Merjenje uspešno izvedenih transakcij ............................................................ 6 2.1.10 Skupna ocena uporabnosti ............................................................................... 6
2.2 Kriteriji zanesljivosti ............................................................................................... 6 2.2.1 Funkcionalno testiranje .................................................................................... 7 2.2.2 Obremenitveno testiranje ................................................................................. 7 2.2.3 Regresijski testi ................................................................................................ 7
2.3 Kriteriji ekonomičnosti ........................................................................................... 7 2.4 Kriteriji varnosti ...................................................................................................... 8 2.5 Kriteriji učinkovitosti .............................................................................................. 9 2.6 Kriteriji, vezani na vzdrževanje ............................................................................ 10 2.7 Kriteriji razvoja ..................................................................................................... 10 2.8 Vsebinski kriteriji ................................................................................................. 10
3 KRITERIJI ZA OCENO METODOLOGIJE RAZVOJA .................................... 11
3.1 Pregled metodologij razvoja ................................................................................. 13 3.1.1 Kaskadni model.............................................................................................. 13 3.1.2 Pristop s prototipi ........................................................................................... 14 3.1.3 Iterativni model .............................................................................................. 14 3.1.4 Agilne metodologije ....................................................................................... 15
3.2 Kriteriji metodologije razvoja programske rešitve ............................................... 20 3.2.1 Uporaba orodij za spremljanje dela razvoja programske rešitve ................... 20 3.2.2 Frekvenca predaje novih verzij ...................................................................... 21 3.2.3 Ustrezna uporaba orodij za hranjenje kode .................................................... 21 3.2.4 Ustrezno definiran postopek za predajo verzije ............................................. 22 3.2.5 Uporaba orodij za sprotno preverjanje, prevajanje in testiranje kode............ 23 3.2.6 Sprotna gradnja in širjenje testov ................................................................... 24 3.2.7 Uporaba orodij za pregledovanje in komentiranje kode ................................ 24
ii
3.2.8 Uporaba orodij za preverjaje pokritosti kode ................................................ 25 3.2.9 Vključitev uporabnikov v razvojni proces ..................................................... 26 3.2.10 Definirani postopki pregledovanja opravljenega dela ................................... 27
3.3 Povzetek kriterijev metodologije razvoja programske rešitve ............................. 27
4 KRITERIJI GLEDE NA VRSTE PROGRAMSKIH REŠITEV ........................... 29
4.1 Vrste programskih rešitev glede na namen ........................................................... 29 4.2 Kriteriji glede na namen programske rešitve ........................................................ 30 4.3 Vrste programskih rešitev glede na tip licenciranja ............................................. 30 4.4 Kriterij glede na tip licenciranja programske rešitve ............................................ 31 4.5 Vrste programskih rešitev glede na način izvajanja ............................................. 31 4.6 Kriterij glede na način izvajanja programske rešitve ........................................... 31 4.7 Vrste programskih rešitev glede na število naročnikov ........................................ 32
4.7.1 Kriteriji za prehod na serijsko rešitev ............................................................ 32 4.7.2 Kriteriji za prehod na rešitev na zahtevo ....................................................... 33
5 KRITERIJI, VEZANI NA ZUNANJI ALI NOTRANJI RAZVOJ PROGRAMSKE REŠITVE ....................................................................................... 34
5.1 Zunanji razvoj programske rešitve ....................................................................... 34 5.1.1 Prednosti zunanjega razvoja .......................................................................... 35 5.1.2 Tveganje zunanjega razvoja .......................................................................... 36 5.1.3 Zunanji razvoj glede na število izvajalcev ..................................................... 37 5.1.4 Zunanji razvoj glede na lokacijo izvajanja .................................................... 37
5.2 Notranji razvoj ...................................................................................................... 38 5.2.1 Prednosti notranjega razvoja .......................................................................... 39 5.2.2 Slabosti notranjega razvoja ............................................................................ 39
5.3 Diagram kriterijev glede na zunanji ali notranji razvoj programske rešitve ........ 40
6 KRITERIJI, VEZANI NA CENO RAZVOJA ........................................................ 42
6.1 Kriteriji zamenjave programske rešitve s kupljeno rešitvijo ................................ 42 6.2 Kriteriji predelave programske rešitve v produkt ................................................. 43 6.3 Kriteriji predaje programske rešitve v skupni razvoj ........................................... 44
7 KRITERIJI, VEZANI NA TEHNOLOGIJO PROGRAMSKE REŠITVE .......... 45
8 RAZVRSTITEV KRITERIJEV ................................................................................ 45
9 IZGRADNJA DIAGRAMA POTEKA ..................................................................... 50
9.1 Diagram poteka ..................................................................................................... 50 9.2 Izdelava odločitvenega diagrama opustitve razvoja programske rešitve ............. 53 9.3 Testiranje diagrama .............................................................................................. 57
9.3.1 Opustitev razvoja programske rešitve za vodenje življenjskih polic v slovenskem zavarovalniškem podjetju .......................................................... 57
9.3.2 Opustitev razvoja programske rešitve za spremljanje opravljenega dela ...... 61
iii
9.4 Prednosti uporabe diagrama poteka ...................................................................... 63 9.5 Slabosti uporabe diagrama poteka ........................................................................ 63 9.6 Priložnosti za izboljšave diagrama poteka ............................................................ 63
SKLEP ................................................................................................................................ 64
LITERATURA IN VIRI ................................................................................................... 66
PRILOGA KAZALO TABEL Tabela 1: Razvrstitev kriterijev ........................................................................................... 46 Tabela 2: Osnovni simboli diagrama poteka ....................................................................... 51
KAZALO SLIK Slika 1: Prednosti razvoja z agilnimi metodologijami pred tradicionalnimi metodami ...... 13 Slika 2: Proces izdelave programske rešitve v kaskadnem modelu razvoja........................ 14 Slika 3: Proces izdelave programske rešitve v iterativnem modelu razvoja ....................... 14 Slika 4: Življenjski cikel ekstremnega programiranja ......................................................... 17 Slika 5: Prikaz procesa Scrum z označenimi fazami in nosilci posamenih faz ................... 18 Slika 6: Prikaz razvojnega delovnega toka Kanban ............................................................ 20 Slika 7: Primer pregleda zahtev v orodju JIRA podjetja Atlassian ..................................... 21 Slika 8: Primer razvejanja kode z uporabo orodja Git......................................................... 22 Slika 9: Primer orodja za sprotno prevajanje, preverjanje in testiranje kode Bamboo ....... 23 Slika 10: Primer orodja za komentiranje kode BitBucket podjetja Atlassian ..................... 25 Slika 11: Primer pregleda pokritosti kode z orodjem Clover podjetja Atlassian ................ 26 Slika 12: Znak neustreznosti uporabljene metodologije...................................................... 28 Slika 13: Vrste programske opreme .................................................................................... 29 Slika 14: Kriteriji, ki jih je potrebno upoštevati glede na izvajalca razvoja ........................ 40 Slika 15: Kriteriji, ki jih je potrebno upoštevati glede na lokacijo produkcijskega okolja . 41 Slika 16: Primer enostavnega algoritma za izpis številk od 0 do 99 ................................... 52 Slika 17: Primer diagrama poteka sprejema pacienta pri zdravniku ................................... 52 Slika 18: Odločitveni diagram opustitve razvoja programske rešitve – 1. del .................... 55 Slika 19: Odločitveni diagram opustitve razvoja programske rešitve – 2. del .................... 56 Slika 20: Odločitveni diagram opustitve razvoja programske rešitve – 3. del .................... 57 Slika 21: Odločitev glede nadaljevanja razvoja programske rešitve za življenjska
zavarovanja zaradi težav s kvaliteto .................................................................... 58 Slika 22: Odločitev glede nadaljnjega razvoja programske rešitve za življenjska
zavarovanja zaradi težav s pomanjkljivimi funkcionalnostmi ............................. 59 Slika 23: Odločitev glede nadaljnjega razvoja programske rešitve za življenjska
zavarovanja zaradi cene razvoja .......................................................................... 60
iv
Slika 24: Odločitev glede nadaljnjega razvoja programske rešitve za vodenje opravljenega dela podjetja Marand leta 2008 ........................................................................... 61
Slika 25: Odločitev glede nadaljnjega razvoja programske rešitve za vodenje opravljenega dela podjetja Marand leta 2016 ........................................................................... 62
1
UVOD Opredelitev problematike. Mnogo podjetij tekom časa razvije lastne programske rešitve za podporo poslovnih procesov. V času nastanka so take rešitve inovativne in pomenijo poslovno prednost, saj običajno takih rešitev na trgu še ni. Za rešitve, ki niso del osnovnega poslovnega procesa, pogosto ni dovolj resursov za sprotno vzdrževanje in posodabljanje, kar lahko resno upočasni nadaljnji razvoj podjetja. Če gre za programsko rešitev, ki rešuje splošne probleme, obstaja velika verjetnost, da se podobne programske rešitve sčasoma pojavijo na trgu, pri čemer so zaradi večjega števila uporabnikov in razvijalcev običajno boljše. Če podjetje svoje programske rešitve ne posodobi oziroma pravočasno zamenja, lahko to dolgoročno pripelje do nekonkurenčnosti in resno ovira nadaljnji razvoja podjetja (Morgan, 2013). Podjetja za podporo svojemu delovanju uporabljajo različne vrste programske opreme, kot so: operacijski sistemi, namizne programske rešitve, podatkovne baze in celovite programske rešitve. Redko podjetja sama razvijajo lastne operacijske sisteme ali podatkovne baze, vendar tudi to ni izključeno. Podjetja, kot so Amazon ali Google, brez lastnih operacijskih sistemov in podatkovnih baz ne bi postala to, kar so. Za vsako programsko rešitev je potrebno ugotoviti, ali trenutna rešitev vsebuje vse funkcionalnosti, ki jih podjetje potrebuje za nemoten nadaljnji razvoj (Wiegers in Beatty, 2013). Tudi če rešitev podpira vse trenutne potrebe, je potrebno zagotoviti dolgoročni razvoj. Vprašanje je, ali ima podjetje na voljo dovolj izučenih kadrov, kakšen je dolgoročni pristop k izobraževanju kadrov in ali je trenutna rešitev tehnološko ustrezna. Pogosto imajo sistemi ustrezne funkcionalnosti, so pa tehnološko zastareli in ni več ustreznih kadrov, ki bi lahko sistem vzdrževali. Tak primer je vzdrževanje starih programskih rešitev COBOL, saj je zelo težko dobiti ustrezno izučene mlade programerje COBOL (Florentine, 2014). Pri odločitvi za zamenjavo programske rešitve je potrebno upoštevati, da, glede na raziskave, samo 60 % informacijskih projektov doseže zastavljene cilje, pri čemer veliki informacijski projekti povprečno za 45 % presežejo predvidene stroške in za 7 % presežejo predvideni čas ter dosežejo za 56 % manj vrednosti, kot je pričakovano (Bonnie, 2015). Dodatno je potrebno razmisliti o morebitnih odvečnih kadrih v primeru nakupa nove končne rešitve ali morebitnih dodatnih kadrih v primeru začetka razvoja nove rešitve (Berdugo, 2014). V vmesnem obdobju uvajanja novega sistema so potrebni kadri tako za vzdrževanje obstoječega kot za razvoj novega sistema. Podjetje, ki se odpove lastnemu razvoju, se mora zavedati morebitne izgube tehnološkega znanja, predvsem pa morebitne izgube poslovnega znanja, do česar pride, če podjetje ni ustrezno vključeno v razvojni proces programske rešitve (Wua, Lia, Chub & Scullib, 2012). Če se razvoj popolnoma prepusti zunanjemu izvajalcu, se dobršen del poslovnega znanja prenese na zunanjega izvajalca. Vmesna pot je, da se samo del razvoja prepusti zunanjim izvajalcem in na tak način podjetje obdrži kot tudi pridobi nova znanja.
2
Cilj in namen dela ter uporabljene metode preučevanja. Namen magistrskega dela je raziskati, kako se podjetja soočajo s presojo smiselnosti nadaljnjega razvoja lastnih rešitev. Pri tem bom raziskal, kakšne možnosti ima podjetje za zamenjavo obstoječe programske rešitve ter na kaj vse mora biti podjetje pozorno, preden se odloči za opustitev nadaljnjega razvoja. Raziskal bom, kdo so deležniki, ki bi morali sodelovati pri tako pomembni odločitvi, in kdo bi moral imeti ključno vlogo. Če podjetje prepozno zazna pomanjkljivosti lastnega razvoja, lahko to bistveno vpliva na konkurenčnost in nadaljnji razvoj podjetja. Zamenjava oziroma predelava lastne rešitve lahko povzroči velike kadrovske spremembe, finančne stroške, pomeni velik poslovni riziko in izgubo poslovnih priložnosti. S takimi odločitvami se soočajo vsa podjetja in odločitve imajo vedno večjo težo, saj so informacijski sistemi vedno pomembnejši oziroma ključni del podjetij. Podjetja se tega vprašanja pogosto lotevajo površno in verjamejo v hitre, enostavne in poceni rešitve, ki pa se nemalokrat izkažejo kot zelo dolgotrajne in drage. Ključno raziskovalno vprašanje je, kateri so kriteriji, ki odločilno vplivajo na odločitev o nadaljnjem razvoju programske rešitve? Osnovne teze magistrskega dela so:
kriterije se da razvrstiti v pregleden diagram poteka;
neustrezna metodologija razvoja lahko onemogoča nadaljnji razvoj programske rešitve;
pojav komercialnih rešitev, ki pokrivajo funkcionalnosti, ki jih podjetje rešuje z lastno programsko rešitvijo, še ne pomeni, da je nadaljnji razvoj lastne rešitve nesmiseln;
glavni kriteriji za opustitev razvoja so funkcionalnosti, kvaliteta in cena. Cilj magistrskega dela je priprava kriterijev v pregledni obliki, na podlagi katerih se odločimo, ali je vzdrževanje lastnega razvoja programske rešitve še smiselno. Izdelal bom diagram poteka, v diagram bodo vključeni vsi kriteriji, ki jih bom odkril tekom raziskave. Diagram poteka bi moral na enostaven in pregleden način pokazati, kaj je potrebno pri tako pomembni odločitvi upoštevati, in na ta način pripeljati do prave odločitve. Pregled vsebine poglavij. Prvi del magistrske naloge vsebuje pregled teoretičnih in praktičnih izsledkov, ki so na to temo na voljo v domači in tuji literaturi. Opisani so modeli razvoja, organizacije razvoja znotraj podjetij ter opredelitve tipov programskih rešitev. V drugem delu je na podlagi zbranih podatkov izdelan diagram poteka, ki vključuje vse kriterije, ki lahko vplivajo na odločitev o nadaljnjem razvoju programske rešitve. Diagram poteka se običajno uporablja za prikaz algoritmov in možnih poti podatkov skozi program, v danem primeru pa bo diagram poteka vodil skozi ustrezni vrstni red odločitev, ki bodo pripeljale do odgovora, ali je nadaljnji razvoj programske rešitve še smiseln, oziroma kaj je potrebno spremeniti, da se upraviči nadaljnji razvoj.
3
1 KLJUČNI KRITERIJI ZA OCENO PROGRAMSKE REŠITVE Pri ocenjevanju smiselnosti nadaljnjega razvoja programske rešitve je potrebno upoštevati tri ključne kriterije:
funkcionalnosti programske rešitve;
kvaliteta programske rešitve;
cena programske rešitve.
To so trije glavni kriteriji, ki so medsebojno povezani. Če je kateri koli izmed naštetih kriterijev neustrezen, je neustrezna celotna programska rešitev. Če je cena previsoka, si rešitve ne moremo privoščiti, če je kvaliteta nezadostna, je programska rešitev neuporabna, in če nam ne nudi vse potrebne funkcionalnosti, je prav tako neuporabna. Funkcionalnosti programske rešitve Upoštevati je potrebno vse funkcionalnosti, ki jih programska rešitev nudi vsem, ki imajo stik s programsko rešitvijo. Ne gre samo za končne uporabnike, temveč tudi za sistemske administratorje, varnostne inženirje, skratka vse, ki pridejo v stik s programsko rešitvijo. Zelo pomembna je tudi možnost razširitev funkcionalnosti. Vprašanje je, ali je dodajanje dodatnih funkcionalnosti izvedljivo in kakšni so stroški izvedbe. Kvaliteta programske rešitve Kvaliteta rešitve tako vključuje stabilnost delovanja, ustrezne rešitve poslovnih procesov, razumljivost za končne uporabnike, njeno uporabnost in skalabilnost. Cena programske rešitve Ustrezna cena je cena, ki je za podjetje sprejemljiva. Dokler podjetju strošek razvoja ni v breme, je cena sprejemljiva. Pomen ustrezne funkcionalnosti, ustrezne kvalitete in cene je zelo odvisen od namena uporabe programske rešitve. Pri programskih rešitvah, ki upravljajo letala, je kvaliteta in zanesljivost programske rešitve dosti bolj pomembna kot količina funkcionalnosti in cena. Dodatna funkcionalnost, ki za upravljanje letala ni ključna, nikoli nima prednosti pred kvaliteto in zanesljivostjo delovanja celotne programske rešitve. Drugače je pri programskih rešitvah za urejanje besedila, kjer je pomembna cena in velik nabor funkcionalnosti, kvaliteta pa ni odločilna. Če se urejevalnik besedila med delovanjem nepričakovano zaustavi, to lahko pomeni kak izgubljen dokument, kar pa je malenkost v primerjavi z izgubo, če se med letom nepričakovano zaustavi programska rešitev za krmiljenje letala.
4
2 KRITERIJI ZA OCENO KVALITETE PROGRAMSKE REŠITVE Pri oceni programske rešitve je potrebno upoštevati različne kriterije, cilje (Planinc, b. l.). Kriterije lahko grobo razdelimo na tehnološke, kadrovske in izvedbene. Če je programska rešitev po določenem kriteriju slaba, to še ne pomeni, da je slaba tudi kot celota. Primeri so tehnološko zastarele programske rešitve, ki pa vsebinsko izjemno dobro pokrivajo poslovne procese.
2.1 Kriteriji uporabnosti Pri uporabnosti se ocenjuje stik končnega uporabnika s programsko rešitvijo. Pomembna sta čas, ki je potreben za razumevanje programske rešitve, in hitrost izvajanja procesov, ko so uporabniki poučeni o delovanju programske rešitve. Zanimiva je tudi primerjava časovnih prihrankov, ki jih programska rešitev nudi v primerjavi z ročnim izvajanjem aktivnosti. Kriteriji uporabnosti, povzeti po (Sauro, 2011):
skladnost s standardi in zakonodajo;
enostavnost in jedrnatost;
celovitost;
razumljivost, preglednost in strukturiranost;
opremljenost z dokumentacijo (priročniki);
podpora odločanju;
povezljivost;
uporabniku prijazen in estetski uporabniški vmesnik. Zgoraj našteti kriteriji so opisni, kar pa ni najbolj uporabno, ko moramo primerjati dva sistema s podobnimi funkcionalnostmi. Za to so primerni metrični kriteriji, s katerimi je primerjava različnih programskih rešitev lažja (Sauro, 2011). Metrični kriteriji so opisani v nadaljevanju.
2.1.1 Ocena izvedljivosti naloge Ocena izvedljivosti naloge (angl. Completion Rates Metric) je enostavna metrika uporabnosti. Običajno se beleži v binarni obliki: 1 pomeni, da je uporabnik nalogo uspešno izvedel, 0 pa pomeni, da uporabnik naloge ni uspel izvesti. Če uporabnik ne more izvesti naloge, druge meritve niso smiselne. Prednost metrike ocene izvedljivosti je njena enostavnost.
5
2.1.2 Težave z uporabnostjo Težave z uporabnostjo (angl. Usability Problems Metric). Pri tej metriki se opiše težavo, na katero naleti uporabnik pri delu z uporabniškim vmesnikom, zabeleži se, kolikokrat in kateri uporabniki so naleteli na težavo. Različni uporabniki bodo imeli različno število težav. Ker težave beležimo za vsakega posameznika posebej, lahko predvidimo kakšne težave bodo imeli različni tipi uporabnikov.
2.1.3 Čas za izvedbo naloge Čas za izvedbo naloge (angl. Task Time Metric) se meri v sekundah ali minutah. Meri se čas od trenutka, ko uporabniki prenehajo z branjem navodil, do trenutka konca izvajanja naloge, upošteva se tudi čas preverjanja. Ta metrika omogoča zelo dobro primerjavo več različnih programskih rešitev, ki omogočajo izvedbo enakih nalog.
2.1.4 Stopnja zadovoljstva ob izvedbi naloge Stopnja zadovoljstva ob izvedbi naloge (angl. Task Level Satisfaction Metric). Takoj po izvedeni nalogi se uporabniku zastavi eno ali več vprašanj glede težavnosti izvedbe naloge. Metrika nam prikaže, kakšna so občutja uporabnikov ob delu s programsko rešitvijo.
2.1.5 Stopnja zadovoljstva po testiranju uporabnosti Stopnja zadovoljstva po testiranju uporabnosti (angl. Test Level Satisfaction Metric). Po zaključku testiranja uporabnosti funkcionalnosti mora uporabnik oceniti nekaj trditev o celostni izkušnji z delom s programsko rešitvijo. Primeri vprašanj, na katera se odgovarja s točkovanjem od 1 do 5, pri čemer 1 pomeni, da se s trditvijo nikakor ne strinjamo, 5 pa pomeni, da se s trditvijo močno strinjamo: 1. Mislim, da bi programsko rešitev rad pogosto uporabljal. 2. Mislim, da je programska rešitev po nepotrebnem komplicirana. 3. Mislim, da je bilo delo s programsko rešitvijo enostavno. 4. Mislim, da bom pri delu s programsko rešitvijo potreboval tehnično pomoč. 5. Mislim, da so v programski rešitvi različne funkcionalnosti dobro integrirane. 6. Mislim, da je v programski rešitvi preveč nekonsistentnosti. 7. Mislim, da se bo večina ljudi hitro navadila uporabljati programsko rešitev. 8. Mislim, da je programska rešitev zelo okorna za uporabo. 9. Pri uporabi programske rešitve sem se počutil varno. 10. Veliko se bom moral še naučiti, preden bom lahko uporabljal sistem.
6
2.1.6 Napake uporabe Napake uporabe (angl. Errors Metric). Beleži se vse nenamerne akcije, napake, ki jih uporabnik ne naredi namenoma med izvajanjem naloge. Vsak primer se zabeleži skupaj z opisom napake. Primer zapisa je: »Uporabnik je v polje 'ime' namesto imena vnesel priimek«. Kasneje se lahko poleg opisa napak doda tudi stopnja nevarnosti napake, da se napake lahko ustrezno klasificirajo. Napake uporabe je smiselno povezati s težavami z uporabniškim vmesnikom. Zbiranje napak uporabe je časovno potratno, saj je poleg testne osebe potreben še moderator, ki napake uporabe beleži.
2.1.7 Pričakovanje uporabnika Pričakovanje (angl. Expectation Metric). Uporabniki imajo neka pričakovanja glede stopnje zahtevnosti določene naloge. Uporabnika se pred izvedbo naloge vpraša o pričakovani težavnosti naloge, to pa se primerja z oceno težavnosti naloge po izvedbi scenarija. Na ta način lahko dobimo dober vpogled, kje so kritični deli programske rešitve.
2.1.8 Število klikov Število klikov (angl. Page Views/Clicks Metric) je osnovna metrika za spletne strani. Pomembno je, kako hitro uporabnik najde določeno funkcionalnost. Veliko število klikov lahko kaže na težave z uporabnostjo programske rešitve.
2.1.9 Merjenje uspešno izvedenih transakcij Merjenje uspešno izvedenih transakcij (angl. Conversion Metric). Primer uporabe je ocenjevanje elektronskih nakupov. Beleži se v binarni obliki, 1 pomeni, da je transakcija uspela, 0 pa pomeni, da transakcija ni uspela.
2.1.10 Skupna ocena uporabnosti Za lažjo primerjavo različnih programskih rešitev se pogosto uporabi skupna ocena uporabnosti, to je ocena, ki je sestavljena iz več različnih kriterijev: stopnje dokončanja naloge, stopnje zadovoljstva ob dokončanju naloge in časa za izvedbo naloge. Metrik za oceno uporabnosti je še veliko, opisal sem samo nekaj najenostavnejših.
2.2 Kriteriji zanesljivosti Zanesljivost programske rešitve je zelo pomembna. Če programska rešitev za isto operacijo vrača različne rezultate ali če programska rešitev operacije izvaja nerazumljivo dolgo, lahko to pripelje do precejšnje poslovne škode. Kriteriji zanesljivosti (Singh & Pal, 2013):
7
natančnost izračuna in prikaza;
konsistentnost baze podatkov;
delovanje brez programskih napak;
ponovljivost operacije. Merjenje zanesljivosti programske rešitve je področje testiranja, ki preverja delovanje programske rešitve v različnih situacijah v določenem časovnem obdobju. Omogoča odkrivanje arhitekturnih napak programske rešitve in tudi funkcionalnih napak. Zanesljivost programske rešitve se meri s povprečnim časom med napakami, to je vsota povprečnega časa do pojavitve napake in časa za njeno odpravo. Če je povprečni čas med napakami 100 ur, to pomeni, da mora programska rešitev 10 ur delovati brez prekinitve (Singh & Pal, 2013). Poznamo tri tipe testiranja zanesljivosti: testiranje funkcionalnosti, obremenitveno testiranje in regresijsko testiranje.
2.2.1 Funkcionalno testiranje Funkcionalno testiranje (angl. Functional Testing) testira vse funkcionalnosti, ki jih nudi programska rešitev. Po izvedbi vsake funkcionalnosti se preveri, ali se je izvedla v skladu s pričakovanji.
2.2.2 Obremenitveno testiranje Cilj obremenitvenega testiranja je testiranje delovanja programske rešitve ob polni obremenitvi sistema. Ob obremenitvah se lahko delovanje programske rešitve zelo upočasni, če pa ima programska rešitev arhitekturne napake, lahko prihaja tudi do napačnega delovanja, recimo do napačnih izračunov.
2.2.3 Regresijski testi Regresijski testi so namenjeni preverjanju tega, ali se po predelavi programske rešitve pojavijo nove napake. Izvedejo se po vsaki spremembi kode.
2.3 Kriteriji ekonomičnosti Programske rešitve so lahko zaradi neustrezne arhitekture ali izvedbe strojno zelo potratne. Dodatna težava je lahko tudi potreba po prevelikem številu potrebnega vzdrževalnega osebja.
8
Kriteriji ekonomičnosti so:
cena za izdelavo dodatnih funkcionalnosti;
cena servisiranja in vzdrževanja;
hitrost izvajanja operacij v primeru dela brez računalniške podpore;
zasedba diskovnega prostora;
zahtevnost v odnosu do strojne opreme.
2.4 Kriteriji varnosti Arhitekturne napake lahko pomenijo velika varnostna tveganja, kot so vdori v informacijski sistem in kraja podatkov. Pri varnosti je zelo pomembno, da ima rešitev ustrezno varnostno kopiranje, ki lahko ob morebitnih nesrečah, kot so požari ali poplave, omogoči restavriranje celotnega sistema, vključno s podatki. Področja varnosti so:
stabilnost baze podatkov in programske opreme;
možnost varnostnih kopij, reševanje podatkovnih katastrof;
izvajanje nadzora nad sistemi in uporabniki;
zaščita pred namernimi in nenamernimi napakami ter vdori. Testiranje varnosti je proces, pri katerem poskušamo odkriti varnostne luknje v mehanizmih za zaščito podatkov in varnostne luknje v funkcionalnosti programske rešitve. Če programska rešitev opravi varnostno testiranje, to še ne pomeni, da je popolnoma varna, saj je vse možnosti nemogoče testirati. Testiranje varnosti preverja naslednje kriterije (Chrillo & Danielyan, 2005):
zaupnost;
integriteta;
avtentikacija;
avtorizacija;
razpoložljivost;
nezatajljivost. Zaupnost pomeni, da programska rešitev omogoča dostop do podatkov samo osebam, ki so jim podatki namenjeni, programska rešitev pa mora preprečevati tudi nepooblaščen pregled podatkov. Z integriteto je opredeljena zaščita podatkov pred nepooblaščenim spreminjanjem, to pomeni, ali lahko zaupamo, da so podatki programske rešitve res taki, kot so bili prvotno vneseni. Programska rešitev mora vsebovati logiko potrjevanja identitete, avtentikacijo vseh uporabnikov programske rešitve, pri čemer so uporabniki fizične osebe,
9
kot tudi druge programske rešitve, s katerimi programska rešitev komunicira. Programska rešitev mora avtorizirati dostop, to je proces, ki omogoča preverjanje, ali ima uporabnik ustrezne pravice za dostop do funkcionalnosti programske rešitve. Za varnost programske rešitve je pomembna tudi razpoložljivost programske rešitve, zagotoviti je potrebno, da so podatki in storitve na voljo takrat, ko jih uporabniki programske rešitve potrebujejo. Z nezatajljivostjo je mišljen proces, ki omogoča, da je prejeto sporočilo prispelo v obliki, kot je bilo odposlano. Pregled ranljivosti programske rešitve lahko razvrstimo v več stopenj. Prva stopnja je spoznavanje delovanja programske rešitve. V tej stopnji še ni predvideno odkrivanje napak, lahko pa se zazna področja, ki bi lahko bila potencialno ranljiva. Naslednja stopnja je pregled ranljivosti sistema, v kateri se z avtomatiziranimi testi pregleda področja, ki so bila spoznana kot potencialno ranljiva v stopnji spoznavanja. Upošteva se pretekla spoznanja o ranljivosti podobnih sistemov. Prvi in drugi stopnji sledi ocena ranljivosti, kjer se poda oceno in priporočila glede posameznih potencialnih ranljivosti sistema, ki so bile najdene v prvih dveh stopnjah. Sledi varnostna ocena, ki temelji na oceni ranljivosti z dodatkom ročnega preverjanja za potrditev izpostavljenosti. Pri varnostni oceni se preverja izpisovanje napak, sistemskih dnevnikov in sistemskih odzivov. Varnostna ocena poskuša pridobiti celostni pogled na programsko rešitev in ne konkretnih ranljivosti sistema. Testiranje vdora simulira poizkus nepooblaščenega dostopa do sistema. Pregled ranljivosti programske rešitve pozna tudi varnostne revizije, pri katerih se običajno osredotoča na manjše področje programske rešitve, ki se ga natančno razišče. Z varnostnim pregledom se potrdi, da so splošni ali interni standardi uporabljani v celotni programski rešitvi.
2.5 Kriteriji učinkovitosti Pri učinkovitosti se preverja, ali programska oprema izkorišča strojno opremo, ki je na voljo. Zastarela programska oprema morda ne zna v celoti izkoristiti moderne strojne opreme, recimo večopravilnosti. Slabo spisana programska oprema lahko po nepotrebnem prekomerno obremenjuje strojno opremo. Kriteriji učinkovitosti so:
večopravilnost;
hitrost procesiranja;
zasedba pomnilnika;
podpora različnim operacijskim sistemom.
10
2.6 Kriteriji, vezani na vzdrževanje Pomembni kriteriji pri oceni programske rešitve so cena vzdrževanja in stroški, ki so povezani z morebitnimi nadgradnjami. Pri oceni stroškov je potrebno upoštevati tudi stroške testiranja in ceno testnega okolja. Kriteriji vzdrževanja (April & Abran, 2008):
prilagodljivost in prenosljivost;
enostavnost namestitve;
enostavnost detekcije napak;
neodvisnost od strojne opreme;
ustrezna tehnična dokumentacija;
možnost administriranja.
2.7 Kriteriji razvoja Ocena razvoja vključuje uporabo ustreznih tehnologij, uporabo ustreznih razvojnih orodij ter ustreznost kadrov. Zastarele tehnologije lahko pomenijo varnostno tveganje, lahko pa pomenijo tudi precejšnjo oviro pri pridobivanju novih kadrov. Če se v razvoj ne vlaga sproti, lahko to pripelje do točke, ko je izvedba nadgradnje tehnološko, časovno in stroškovno neizvedljiva in je cenejša rešitev izdelava nove programske rešitve. Kriteriji razvoja so:
ustreznost/reference uporabljenih tehnologij;
ustreznost razvojnih orodij;
razvojni proces;
vlaganje v razvoj;
izobraževanje;
komunikacija z uporabniki;
možnost nadgrajevanja.
2.8 Vsebinski kriteriji Programska rešitev lahko ustrezno rešuje potrebe poslovnega procesa. Do težav pride, ko obstoječa programska rešitev usmerja poslovni proces in ne obratno. Pri uporabi starih programskih rešitev je pogosto, da se poslovnega procesa ne da spremeniti, ker se ne da spremeniti delovanja programske rešitve. Pri oceni je potrebno upoštevati pokritost
11
poslovnih procesov s programsko rešitvijo, predvsem to, ali so pokriti kritični in nujno potrebni poslovni procesi. Vsebinski kriteriji so:
skladnost s poslovnimi procesi;
pokritost poslovnih procesov;
ustrezna predstavitev poslovnih procesov.
3 KRITERIJI ZA OCENO METODOLOGIJE RAZVOJA Pri določanju kriterijev za opustitev razvoja programske rešitve ne moremo iti mimo metodologije razvoja programske rešitve. Preveliki stroški programske rešitve, pomanjkljive in neustrezne funkcionalnosti ter pogoste napake so lahko posledica neustrezne metodologije oziroma neustrezne implementacije procesov metodologije. Preden se zaradi naštetih težav dokončno odločimo za opustitev programske rešitve, lahko poizkusimo z uvedbo drugačnih procesov razvoja oziroma z zamenjavo metodologije razvoja. V nadaljevanju sledi opredelitev pojma metodologija razvoja, nato kratka predstavitev najbolj znanih metodologij, na koncu pa so opredeljeni kriteriji, na podlagi katerih lahko ocenimo metodologijo razvoja programske rešitve. Procesi razvoja programske opreme so postopki za načrtovanje, razvoj, dostavo in podporo programskim rešitvam in se ne ukvarjajo s tehničnim delom razvoja programskih rešitev, temveč z upravljanjem razvoja programske opreme. Metodologija je več kot le proces, saj določa nabor dogovorjenih procesov, ki se uporabijo pri razvoju, poleg tega pa običajno obsega tudi filozofski in kulturni pogled na razvoj. Tekom časa so se oblikovale različne metodologije, vse pa naj bi omogočile (Braude & Bernstein, 2016, str. 1):
standardiziran proces razvoja;
sledljivost razvoja;
pričakovane rezultate;
rešitve, izdelane v pričakovanih rokih;
rešitve, izdelane v okviru predvidenih stroškov;
kakovosten končni izdelek.
Za dosego naštetih ciljev mora metodologija določiti razmerja med osnovnimi gradniki razvoja:
ljudje – razvijalci, uporabniki, stranka;
12
produkt – programska rešitev s pripadajočo dokumentacijo;
projekt – potrebne aktivnosti za izdelavo programske rešitve;
proces – postopki, s katerimi izvedemo aktivnosti za izdelavo programske rešitve.
V začetkih se je pri razvoju programske opreme posnemalo klasične razvojne modele, ki so se uporabljali v proizvodnji in pri gradnji. Značilnost teh modelov je, da so naknadne spremembe skoraj nemogoče. Primer je gradnja hiše, kjer je po tem, ko je hiša že narejena, zelo težko zamenjati tip zidaka. Taki modeli spadajo v sklop tradicionalnih pristopov k razvoju. Zanje je značilno, da se pred začetkom dejanskega programiranja naredi dokončno podrobno analizo, ki se kasneje ne spreminja. Eden prvih predstavnikov tradicionalnih metodologij je kaskadni model razvoja. Sčasoma se je pokazalo, da klasični razvojni modeli običajno niso primerni za razvoj programske opreme, saj je skoraj nemogoče vnaprej narediti tako podrobno analizo, da se kasneje tekom razvoja ne bi spreminjala. Skoraj vedno se namreč ugotovi, da so prvotne zahteve pomanjkljive, pogosto pa tudi napačne. Na podlagi teh izkušenj so se postopno razvili agilni pristopi k razvoju programske opreme. Značilnost agilnih pristopov je izjemna prilagodljivost glede na spremembe zahtev. Glavne razlike med tradicionalnimi in agilnimi pristopi so, da slednji v ospredje postavljajo posameznike in interakcije med njimi (namesto vnaprej določenih procesov in orodij), da je na prvem mestu delujoč izdelek (in ne natančna dokumentacija o njem), da je tesno sodelovanje z naročnikom in medsebojno zaupanje pomembnejše od pogodbenih pogajanj ter da je prilagajanje sprotnim spremembam in novim okoliščinam pomembnejše od togega sledenja vnaprej zastavljenemu načrtu. Posledice takega pristopa so izboljšanje preglednosti, prilagodljivosti in takojšnje poslovne vrednosti ter zmanjšanje tveganja tekom razvoja, kot je razvidno iz slike 1. Preglednost projekta je pri agilnih pristopih tekom celotnega razvoja enaka, saj se jasno vidi kako izdelava programske rešitve napreduje. Izdelave programske rešitve se lotimo takoj, za razliko od klasičnih pristopov, kjer se s samo implementacijo začne šele po končani fazi analize in načrtovanja. Prilagodljivost je vgrajena v samo jedro agilnih pristopov, saj se vsak korak razvoja načrtuje sproti, kar pomeni, da se načrtovanje izvaja in popravlja tekom celotnega obdobja razvoja, za razliko od klasičnih pristopov, kjer ni predvideno, da se tekom implementacije spreminja specifikacije. Poslovna vrednost produkta je pri agilnih pristopih takoj merljiva, saj že od samega začetka razvoja predvideva delujoč prototip, kar pa ne velja za klasični pristop, kjer se z implementacijo čaka, dokler se ne zaključita analiza in načrtovanje.
13
Posledica prototipov že na samem začetku razvoja je zmanjšanje tveganja, saj sproti vidimo ali gre projekt v pravo smer ali ne. Primerjava med klasičnim in agilnim pristopom glede na transparentnost, prilagodljivost, poslovno vrednost in tveganje je razvidna iz slike 1.
Slika 1: Prednosti razvoja z agilnimi metodologijami pred tradicionalnimi metodami
Vir: prednosti agilnega razvoja, b. l.
Metodologije razvoja lahko delimo na štiri osnovne pristope (Kašnik, 2014, str. 3):
tradicionalni modeli (kaskadni ali zaporedni in inkrementalni modeli);
evolucijski modeli (iterativni, prototipni in spiralni modeli);
agilne metode (ekstremno programiranje, Scrum, Lean itn.);
kombinirani modeli.
3.1 Pregled metodologij razvoja
3.1.1 Kaskadni model Kaskadni ali zaporedni model je predstavnik tradicionalnih modelov. Sestavljen je iz petih zaporednih stopenj, ki se med seboj ne prekrivajo. Projekt prehaja preko vseh pet stopenj in se ne vrača v predhodne stopnje. Model je leta 1970 prvič formalno opisal Winston W. Royce, a ga je predstavil kot nedelujoč model, ki se v praksi ne obnese.
14
Model je ameriško ministrstvo za obrambo leta 1985 predpisalo kot standard razvoja. Slabost takega pristopa je, da se poslovna vrednost pokaže šele tik pred koncem projekta.
Slika 2: Proces izdelave programske rešitve v kaskadnem modelu razvoja
Vir: W. Royce, Managing the Development of Large Software Systems, 1970, str. 2
3.1.2 Pristop s prototipi Pri tem pristopu se tekom razvoja pripravlja delujoče prototipe, nepopolne dele bodoče programske rešitve, ki ne vsebuje končne funkcionalnosti. Prototipe uporabniki sproti ocenjujejo in testirajo. Prototipi se lahko zavržejo, lahko pa tekom razvoja postanejo prave delujoče programske rešitve. Vsak prototip vsebuje majhen dodaten košček nove funkcionalnosti. Pristop s prototipi ni metodologija, temveč je orodje, ki je lahko del razvojne metodologije.
3.1.3 Iterativni model Iterativni model razvoja si lahko predstavljamo kot serijo več manjših kaskadnih razvojev, kjer je celoten kaskadni cikel izveden za manjši del predvidene programske rešitve.
Slika 3: Proces izdelave programske rešitve v iterativnem modelu razvoja
Zahteve TestiranjeNačrtovanje Izvedba
Zahteve TestiranjeNačrtovanje Izvedba
Zahteve TestiranjeNačrtovanje Izvedba
1. Iteracija
2. Iteracija
3. Iteracija
Vir: W. Royce, Managing the Development of Large Software Systems, 1970
Zahteve
Načrtovanje
Izvedba
Testiranje
Vzdrževanje
15
Cilj je, da se velik projekt razbije na več manjših obvladljivih kosov. Vsak manjši kos se razvija s kaskadnim pristopom, pri čemer se lahko uporablja prototipiranje za sprotno preverjanje ustreznosti. Z vsakim novim podprtim kosom se bližamo končni delujoči programski rešitvi.
3.1.4 Agilne metodologije Agilne metodologije so skupek več postopkov za razvoj programske opreme in temeljijo na iterativnem razvoju, pri čemer se zahteve in rešitve razvijajo v tesnem sodelovanju med samoorganiziranimi heterogenimi timi in stranko. Sam termin je nastal leta 2001, ko se je v mestu Utah (Higsmith, 2002, str. xvii) zbrala manjša skupina strokovnjakov in razpravljala o trenutnem stanju razvoja. Takrat je nastal agilni manifest (angl. Manifesto for Agile Software Development). Agilni manifest je povzet v sledečih osnovnih principih:
posamezniki in interakcije pred procesi in orodji;
delujoča programska oprema pred vseobsežno dokumentacijo;
sodelovanje s stranko pred pogodbenimi pogajanji;
odziv na spremembe pred togim sledenjem načrtom.
Pojavilo se je več različnih modelov agilnih metodologij, tukaj je nekaj najbolj razširjenih:
SCRUM;
XP – ekstremno programiranje;
TDD – testno voden razvoj;
LSD – vitek razvoj programske opreme;
KANBAN;
agilno modeliranje. Vsaka izmed metodologij ima svoj pristop k agilnosti in vsaka nudi tehnike, ki jih lahko uporabljamo, tudi če ne privzamemo celotne metodologije. 3.1.4.1 Ekstremno programiranje Ekstremno programiranje bi lahko povzeli z dvanajstimi praksami, ki jih lahko grupiramo v štiri področja (Beck, 2000):
16
Hiter odziv - Programiranje v paru – kodo pišeta dva programerja hkrati, pri tem ni potrebno,
da sta enako usposobljena. - Igre planiranja – tedenski sestanki, ki določijo naslednjo fazo. - Celosten tim – razvojni tim mora biti sestavljen iz različnih profilov zaposlenih,
predstavnik stranke mora biti del razvojnega tima. - Testno voden razvoj – najprej se naredi teste, šele nato se spiše koda.
Neprekinjen razvoj - Stalna integracija – orodja, ki avtomatično gradijo, testirajo in predajajo
programsko rešitev. - Preoblikovanje kode – če se tekom razvoja ugotovi, da koda ni optimalna, se
spodbuja predelavo in optimizacijo kode. - Majhne predaje – ko je neka funkcionalnost podprta, se jo takoj preda, razvojni
cikli so kratki.
Skupno razumevanje - Standardi kodiranja – predpisane oblike kodiranja, običajno se ustreznost kode
preverja avtomatsko. - Skupno lastništvo kode – vsak programer ima pravico in dolžnost popravljati vse
dele kode. - Enostavnost ima prednost – vedno se išče preproste rešitve. - Vsem razumljive metafore – skrbi se, da so poimenovanja v kodi razumljiva
vsem, tako programerjem kot strankam.
Dobro počutje programerjev - Delovni čas – delovni čas naj ne bi presegal 40 ur tedensko.
Življenjski cikel ekstremnega programiranja sestavlja šest faz (Rojko, 2011):
faza raziskovanja;
faza načrtovanja;
faza ponovitev do objave;
faza priprave za produkcijo;
faza vzdrževanja;
faza smrti.
17
Slika 4: Življenjski cikel ekstremnega programiranja
Zgodbe
Redneposodobitve
PrioriteteOcene izvedbe
Programiranje v parih
Faz
a p
rip
rave
za
prod
uk
cijo
Faz
a vz
drž
evan
ja
Faz
a sm
rti
AnalizaNačrtovanje in
modeliranje
Načrt testiranja Testiranje
Neprestano preverjanje
TestSkupnabaza
Neprestana integracijaPovratna informacija
Man
jša
razl
ičic
a
Pos
odob
ljen
a ra
zlič
ica
Kon
čna
razl
ičic
a
Odobritev naročnika
Vir: M. Rojko, Uporaba agilne metodologije »SCRUM« pri razvoju državnega portala za poslovne
subjekte, 2011, str. 17
3.1.4.2 Scrum Prve omembe Scruma segajo v leto 1986, ko sta ga Hirotaka Takeuchi in Ikujiro Nonaka definirala kot »fleksibilno, celovito strategijo razvoja produkta, kjer razvojni tim deluje kot ekipa, da doseže skupni cilj«, končno obliko pa je dobil leta 2001, ko sta ga K. Schwaber in M. Beedle opisala v knjigi Agile Software Development with Scrum. Značilnosti Scruma so:
majhne ekipe do šest članov;
sprotno preverjanje;
poudarek na sodelovanju;
prilagodljivost.
Vloge na projektu Scrum so:
skrbnik metodologije – skrbi za nemoteno delovanje procesa Scrum in ne projekta, ni projektni vodja;
predstavnik naročnika – preverja, ali ekipa ustrezno deluje v poslovnem smislu;
18
razvojna ekipa – skupina oseb različnih profilov, odgovornih za razvoj programske opreme.
Slika 5: Prikaz procesa Scrum z označenimi fazami in nosilci posamenih faz
Zbirkazahtev in ciljevprojekta
Lastnikprodukta
Zbirkazahtev in ciljeviteracije
Vodja scrum-a
Projektna ekipa razširi zahteve in cilje
Projektnaekipa
Projektnaekipa
Projektnaekipa
Ocena uspešnosti in napredka
30 dni
sprint
24 ur
15 minutni dnevni scrum
sestanki
Vir: Baškovec, Agilne metode managmenta projektov s poudarkom na metodi Scrum na primeru
razvoja GPS storitve, str. 12
Proces Scrum predpisuje naslednje dogodke (Hauer, 2013):
sestanek za načrtovanje sprinta – dogovor, kaj se bo naredilo v naslednjem sprintu;
sprint – razvojni cikel, traja od enega do štirih tednov;
dnevni Scrum – dnevni sestanek do 15 minut, priporočeno je, da se tekom sestanka stoji;
revizija sprinta – sestanek po koncu sprinta, kjer se pregleda, kaj je bilo narejeno in kaj ni bilo narejeno, opravljeno se predstavi naročniku;
retrospektiva sprinta – sestanek po koncu sprinta, kjer se preveri, kaj je bilo dobro in kaj slabo v zadnjem sprintu, določi se morebitne izboljšave postopkov.
Artefakti Scrum:
seznam zahtev izdelka – seznam vseh zahtev, ki jih mora podpirati končni izdelek, za prioritete skrbi naročnik;
19
seznam zahtev sprinta – seznam zahtev, ki so predvidene, da bodo izvršene v sprintu, določi se jih na začetku sprinta. Zahteve se oceni in se jim določi točke zahtevnosti;
graf preostalih točk sprinta – grafična predstavitev napredka sprinta;
uporabniška zgodba – opis zahteve s perspektive uporabnika.
Pri Scrumu se pogosto uporablja termin hitrost ekipe (angl. Velocity), ki ponazarja količino dela, ki ga ekipa lahko opravi v enem dnevu. Pomemben je tudi termin poker planiranja (angl. Planning Poker), to je metoda, s katero presenetljivo učinkovito celotna ekipa oceni posamezne zahteve. 3.1.4.3 Kanban Kanban je bil razvit kot sistem za planiranje in vodenje proizvodnje s ciljem nizkih zalog in istočasnega povišanja dobavne pripravljenosti. Zgledoval se je po sprotni nabavi v trgovskih blagovnicah, kjer imajo na zalogi samo toliko blaga, kolikor pričakujejo, da ga bodo prodali (angl. Just In Time). Izvorni sistem je leta 1947 razvil Taiichi Ohno v japonskem tovornem podjetju Toyota (Simona Groznik, 2009). Osnova Kanbana je boljša komunikacija preko vizualnega vodenja. David J. Andersen je bil prvi, ki je opisal uporabo principov Kanbana pri razvoju informacijskih sistemov. Štirje principi Kanbana (Ograjenšek, 2013):
vizualizacija poteka dela – s pomočjo diagramov poteka dela;
omejitev prostega teka – poskusi se omejiti količine dela v toku;
modeliranje delovnega toka – uravnavanje ravnovesja med povpraševanjem in propustnostjo;
nepretrgano izboljševanje – poizkuša se nove prijeme in kasneje analizira njihovo učinkovitost.
Potek delovnega toka se v Kanbanu vizualizira s pomočjo fizične ali virtualne tabele s karticami. Kartice predstavljajo naloge, ki jih je potrebno izvršiti, le-te se premikajo od leve proti desni, pri čemer prehajajo skozi posamezne stolpce, ki predstavljajo aktivnosti razvoja. Na kartici je poleg imena in kratkega opisa naloge zapisano, kdo je trenutno določen za izvedbo naloge. Tak pregled omogoča dober vpogled v stanje na projektu in hitro odkrivanje morebitnih zastojev. Končni cilj je, da kartice čim manj časa stojijo in da kar se le da hitro prehajajo skozi različne faze razvoja. Primer pregleda delovnega toka je predstavljen na sliki 6. V predstavljenem primeru imamo sedem stolpcev: za narediti, analiza v delu, analiza narejeno, razvoj v delu, razvoj narejeno, test in predaja. Zahteve so predstavljene z barvnimi kvadratki, pri čemer barva določa vrsto
20
zahteve. Zahteve prehajajo preko stolpcev od leve proti desni, stolpci predstavljajo aktivnosti razvoja.
Slika 6: Prikaz razvojnega delovnega toka Kanban
Za narediti Analiza Razvoj
V delu Narejeno V delu Narejeno
Test Predaja
Uporabniške zgodbe
Napake Zahteve Izboljšave
Vir: A. Ograjenšek, Uporaba metode Kanban pri razvoju programske opreme, 2013, str. 8
3.2 Kriteriji metodologije razvoja programske rešitve Opisane metodologije razvoja vsebujejo orodja in pristope k razvoju, ki lahko bistveno prispevajo k ceni, kakovosti in funkcionalnosti programske rešitve. Kriteriji, na podlagi katerih lahko ocenimo metodologijo razvoja, so predstavljeni v nadaljevanju.
3.2.1 Uporaba orodij za spremljanje dela razvoja programske rešitve Bistveno pri razvoju programske rešitve je, da je na voljo ustrezno orodje, ki omogoča pregled izvedenih in načrtovanih zahtev na projektu. Projekt se lahko spremlja tudi na fizični tabli, še bolje pa je, da se za to uporablja ustrezna orodja. Ne glede na način, s katerim se projekt spremlja, je pomembno, da je postopek spremljanja jasen in da se postopki izvajajo. Pogosto se pri programskih rešitvah zahtev ne vodi na strukturiran način, pogosto se zahteve pošiljajo po elektronski pošti, kar pa lahko privede do prelaganja odgovornosti ob morebitnih napakah in do izgube dejanskih navodil za izvedbo.
21
Plačljivi orodji, ki sta trenutno uveljavljeni, sta JIRA podjetja Atlassian in Rally podjetja CA Technologies, na voljo pa so tudi odprtokodne rešitve, kot je na primer MyCollab (Muilwijk, 2016).
Slika 7: Primer pregleda zahtev v orodju JIRA podjetja Atlassian
3.2.2 Frekvenca predaje novih verzij To, kako hitro je na voljo verzija s popravki morebitnih napak in kako pogosto je na voljo verzija z novimi funkcionalnostmi, je zelo pomembno. Maksimalna priporočljiva dolžina iteracije je tri tedne (Highsmith, 2013).
3.2.3 Ustrezna uporaba orodij za hranjenje kode Preveri se, ali so vse spremembe kode evidentirane in shranjene v repozitoriju. Novejši repozitoriji omogočajo enostavno razvejanje kode in enostavno združevanje kode. Uporaba ustreznih orodij lahko bistveno vpliva na čas, potreben za izdelavo novih funkcionalnosti. Z ustreznim upravljanjem razvojnih vej lahko dosežemo bistvene prihranke v času, saj lahko istočasno razvijamo in testiramo več funkcionalnosti, vsako v svoji veji. Ker se funkcionalnosti razvijajo vsaka v svoji veji, se med razvojem razvijalci ne motijo, do
22
konfliktov pride samo ob združevanju vej. Metodologija mora zapovedovati ustrezne postopke za vodenje sprememb kode. Orodja, ki se trenutno najbolj uveljavljajo, so narejena na osnovi Git. Primera takih orodij sta GitHub in BitBucket. Na voljo so odprtokodne in plačljive rešitve (Git Basics).
Slika 8: Primer razvejanja kode z uporabo orodja Git
v0.1 v0.2 v0.3
Glavna Predaja RazvojNova
funkcionalnostNova
funkcionalnost
Vir: Comparing Workflows, b. l.
3.2.4 Ustrezno definiran postopek za predajo verzije Opredeljen mora biti postopek za pripravo in predajo verzije. Pod tem je mišljeno, kako se označi kodo, ki je bila predana, kako se opiše spremembe, ki so bile izvedene v novi verziji, in morebitne odpravljene napake, kakšen je postopek testiranja pred predajo, kakšen je postopek predaje verzije in postopek prevzema verzije ter kdo mora biti obveščen o predaji (Rojko, 2011).
23
3.2.5 Uporaba orodij za sprotno preverjanje, prevajanje in testiranje kode Bistveno pri razvoju je, da se napake odkrijejo zgodaj. Več časa kot mine od nastanka do odkritja napake, večja je škoda, ki jo napaka povzroči. Pomemben kriterij razvoja programske rešitve je, ali ustrezno uporablja orodja za sprotno prevajanje in testiranje kode. Potrebno je preveriti, ali metodologija ustrezno upošteva rezultate sprotnega preverjanja kode in ali je v metodologiji ustrezno definirano, kdaj je potrebno kreirati nove teste. Na voljo so odprtokodne rešitve, kot je Hudson, ali pa plačljive, kot je Bamboo podjetja Atlassian. Vsa orodja omogočajo razširitev z dodatnimi preverjanji, kot je statična analiza kode. Primera orodij za statično analizo kode sta Sonar, ki vključuje PMD, in FindBugs.
Slika 9: Primer orodja za sprotno prevajanje, preverjanje in testiranje kode Bamboo
24
3.2.6 Sprotna gradnja in širjenje testov Avtomatično testiranje je zares uporabno samo, če je izdelava testnih primerov integrirana v metodologijo razvoja. To pomeni, da metodologija jasno definira, kdaj in kdo je zadolžen za kreiranje testov, ki pokrivajo novo nastalo funkcionalnost (Myers & Sandler & Badgett, 2012). V primeru metodologije testno vodenega razvoja je pisanje testov predvideno pred pisanjem funkcionalnosti, kar pa ni vedno izvedljivo. Težko je narediti test uporabniškega vmesnika, še preden je uporabniški vmesnik narejen. Pomembno pa je, da metodologija predpiše, da se vsaka nova funkcionalnost doda v teste, še preden se nova funkcionalnost preda v produkcijo. Če se izdelava testov odlaga na kasnejši čas, to običajno pomeni, da se testi nikoli ne naredijo. V pomoč je lahko sprotno avtomatizirano preverjanje pokritosti kode s testi in avtomatizirano javljanje napak, če pokritost kode pade pod določen minimum.
3.2.7 Uporaba orodij za pregledovanje in komentiranje kode Pomembno orodje za dvig kvalitete programske rešitve je medsebojno pregledovanje kode, preden se koda preda v uporabo. Običajni pristop je, da programer vsako novo napisano kodo s pomočjo orodja za pregledovanje in komentiranje kode pred predajo v glavno razvojno vejo preda v odobritev enemu ali več programerjem. Pregledovalec kode po elektronski pošti ali preko kakega drugega sporočilnega sistema prejme obvestilo o zahtevanem pregledu, nato preko spletnega vmesnika spremembe pregleda in jih potrdi, ali pa tudi zavrne. V primeru zavrnitve s pomočjo orodja poda komentarje na konkretne razrede in vrstice v kodi, kjer vidi težave, avtor kode nato prejme obvestilo o komentarjih, na komentarje odgovori, poda dodatne razloge, zakaj je prvotna rešitev pravilna, ali pa kodo ustrezno popravi in jo ponovno preda v pregled. Tako se lahko na določenem delu kode izmenjujejo komentarji, vse dokler se vsi udeleženci ne strinjajo, da je rešitev pravilna, šele takrat se lahko nova koda združi z glavno razvojno vejo. Na ta način se lahko odkrije veliko programerskih napak in tudi napak specifikacije. Ker pri pregledu sodeluje več programerjev, je večja verjetnost, da bodo skupaj odkrili, da je neka specifikacija neustrezna. Vsak programer ne more poznati vsebine celotne programske rešitve, skupaj pa jo poznajo. Pregledovanje kode poleg odkrivanja napak v kodi omogoča tudi širjenje znanja, saj lahko izkušenejši programerji na ta način poučujejo nove, še neizkušene programerje. Ni pa tako redko, da novi programerji na tak način kaj novega naučijo izkušene programerje. Poleg tega se s pregledovanjem kode lažje uveljavi standarde glede izgleda in načina programiranja. Obstajajo odprtokodne rešitve, kot je GitLab, ali pa plačljive, kot je BitBucket podjetja Atlassian.
25
Slika 10: Primer orodja za komentiranje kode BitBucket podjetja Atlassian
3.2.8 Uporaba orodij za preverjaje pokritosti kode Pri testiranju je zelo pomembno, da vemo, kakšen delež kode in funkcionalnosti je pokrit z avtomatičnimi testi. Uporaba orodij, ki to omogočajo, lahko zelo pripomore k ustreznemu pisanju testov. Tako orodje omogoča pregled posameznih razredov in z zeleno barvo obarva dele kode, ki se s testi dejansko izvedejo, ter z rdečo dele kode, ki se s testi ne izvedejo. Za posamezne pakete kode in celotno programsko rešitev določi stopnjo pokritosti kode. S pregledom TreeMap lahko zelo hitro ugotovimo, kateri deli kode so slabo pokriti s testi (Atlassian, Clover). Na voljo so odprtokodne in plačljive rešitve, primer odprtokodne je Cobertura, primer plačljive pa Clover podjetja Atlassian.
26
Slika 11: Primer pregleda pokritosti kode z orodjem Clover podjetja Atlassian
3.2.9 Vključitev uporabnikov v razvojni proces Če razvoj poteka mimo želja in potreb uporabnikov, bo rezultat pomanjkljiva in neustrezna funkcionalnost. Preveriti je potrebno, ali metodologija v razvoj ustrezno vključuje tudi končne uporabnike (Hauer, 2013). Agilne metodologije zato predvidevajo, da je naročnik del razvojnega tima, kar pa ni vedno izvedljivo. Kadar to ni mogoče, je potrebno zagotoviti redno komunikacijo med uporabniki in razvijalci. Dobra praksa je, da razvijalci občasno obiščejo uporabnike programske rešitve, saj na ta način razvijalci dobijo boljši vpogled v to, na kakšen način se njihova programska rešitev uporablja v praksi. Enako pomembno je, da imajo uporabniki možnost obiska razvoja, saj lahko na ta način spoznajo in lažje razumejo težave na strani razvoja.
27
3.2.10 Definirani postopki pregledovanja opravljenega dela Različne metodologije imajo različne pristope k pregledovanju opravljenega dela. Pri Scrumu se po vsakem intervalu razvoja izvede retrospektiva, sestanek celotnega razvojnega tima, kjer se pregleda opravljeno delo in preveri, ali so bili postopki pri razvoju ustrezni. Redni pregledi in ocenjevanje dela pripomorejo k pravočasnemu odkrivanju in odpravljanju težav (Hauer, 2013). Na retrospektivi imajo člani razvojne ekipe možnost izpostaviti pomanjkljivosti, ki so bile narejene v zadnjem razvojnem ciklu, in skupaj se lahko odkrije rešitev za odpravo pomanjkljivosti. Če takih sestankov ni, se pogosto zgodi, da vsaj nekaj članov ekipe pozna težave, a ta informacija ne pride do drugih članov ekipe, ki bi težavo lahko rešili. Člani ekipe se pogosto ne zavedajo, da pomanjkljivosti, ki jih ignorirajo, vplivajo tudi na druge člane ekipe, in da bi odprava le-teh lahko precej pospešila razvoj. Ali gre res za pomanjkljivost takega tipa, pa se lahko ugotovi samo ob razpravi celotne ekipe, zato je pomembno, da se nameni čas skupnim sestankom, kjer se pogovori o opravljenem delu.
3.3 Povzetek kriterijev metodologije razvoja programske rešitve Neustrezna metodologija pri razvoju lahko pripelje do neuporabne programske rešitve. Če ima programska rešitev težave s kvaliteto, funkcionalnostmi ali ceno, obstaja velika verjetnost, da je vzrok v neustrezni metodologiji razvoja. Ustreznost metodologije se lahko preveri s predhodno opisanimi kriteriji metodologije razvoja. Če obstaja sum, da je vzrok težav neustrezna metodologija, in se hkrati oceni, da je programska rešitev strateškega pomena za podjetje in podjetje želi nadaljevati z razvojem, se programsko rešitev lahko izboljša z implementacijo ustreznejše razvojne metodologije. Pri izbiri metodologije in uvajanju posameznih procesov metodologije je potrebno upoštevati obstoječi način dela. Uvedba nove metodologije mora biti postopna, sproti je potrebno ocenjevati učinke, saj prehitro, nekritično uvajanje nove metodologije lahko stanje še poslabša. Na sliki 12 je prikazano, s katerimi procesi metodologij lahko rešujemo različne težave pri razvoju programske rešitve. Najprej se vprašamo, kaj je naša največja težava razvoja, glede na odgovor nato sledimo povezavam, ki pripeljejo do ustreznega odgovora. Kot odgovor dobimo naštete kriterije, s katerimi lahko odpravimo težavo pri razvoju programske rešitve. Z ustreznimi prilagoditvami razvojne metodologije se lahko težave razvoja omili ali pa tudi popolnoma odpravi.
28
Slika 12: Znak neustreznosti uporabljene metodologije
Programskarešitev ima
težave z
Začetek
Neustreznafunkcionalnost
•Uporaba orodij za spremljanje razvoja programske rešitve
•Vključitev uporabnikov v razvojni proces
•Definirani postopki pregledovanja
opravljenega dela
Pogoste napake
Napake so
Preveri• Ustrezna uporaba orodij za hranjenje
kode • Uporaba orodij za sprotno preverjanje,
prevajanje in testiranje kode
• Definirani postopki
pregledovanja opravljenega dela
• Uporaba orodij za preverjaje pokritosti
kode
Preveri•Ustrezna uporaba orodij za hranjenje
kode •Uporaba orodij za sprotno preverjanje,
prevajanje in testiranje kode
•Sprotna gradnja in širjenje testov
•Uporaba orodij za pregledovanje in
komentiranje kode•Definirani postopki
pregledovanja opravljenega dela•Uporaba orodij za preverjaje pokritosti
kode
Preveri•Ustrezno definiran postopek za predajo
verzije•Uporaba orodij za sprotno preverjanje,
prevajanje in testiranje kode
•Sprotna gradnja in širjenje testov•Vključitev
uporabnikov v razvojni proces
•Uporaba orodij za pregledovanje in
komentiranje kode•Definirani postopki
pregledovanja opravljenega dela•Uporaba orodij za preverjaje pokritosti
kode
Ponavljajoče Vedno novePri novih
funkcionalnostih
•Ustrezno definiran postopek za predajo
verzije•Vključitev
uporabnikov v razvojni proces
•Definirani postopki pregledovanja
opravljenega dela
Težave ob nameščanju
Vir: povzeto po opisu metodologij različnih avtorjev
Metodologija, ki bi ustrezala vsem situacijam in razmeram v vseh razvojnih okoljih, ne obstaja. Pregled metodologije razvoja je zelo pomemben del procesa odločitve o opustitvi internega razvoja programske rešitve, saj lahko z ustrezno metodologijo bistveno vplivamo na kvaliteto, funkcionalnosti in ceno programske rešitve.
29
4 KRITERIJI GLEDE NA VRSTE PROGRAMSKIH REŠITEV Programske rešitve lahko delimo glede na namen uporabe, tip licenciranja, način izvajanja in število naročnikov. V nadaljevanju so predstavljeni posamezni tipi programskih rešitev, na koncu pa še, kakšen je vpliv tipa programske opreme na kriterije opustitve lastnega razvoja.
4.1 Vrste programskih rešitev glede na namen Glede na namen uporabe programske rešitve oziroma programsko opremo grobo delimo na sistemsko programsko opremo in namensko programsko opremo. Sistemsko programsko opremo lahko nadalje razdelimo na operacijske sisteme, programsko opremo za razvoj programske opreme in pomožno programsko opremo (Patterson, 2016).
Slika 13: Vrste programske opreme
Vir: The Types of Software Broken Down, (2012)
Operacijski sistem – programska rešitev, ki se prva naloži v računalnik. Skrbi za strojno opremo računalnika in programskim rešitvam dodeljuje vire, kot so pomnilnik, procesor ter diski. Programska oprema za razvoj programske opreme – programska oprema, namenjena razvijalcem programske opreme. Omogoča pisanje in pretvorbo programske kode v strojno
Programska oprema
Sistemska programska
oprema
Operacijski sistem
Programska oprema za
razvoj programske
opreme
Pomožna programska
oprema
Namenska programska
oprema
Podatkovne baze
Poslovna programska
oprema
Urejevalniki besedil ..
30
kodo. Programska koda je zapis programa v obliki, ki je razumljiva ljudem, strojna koda pa je koda, ki se lahko izvaja v strojni opremi. Pomožna programska oprema – programska oprema, namenjena vzdrževanju računalnika. Primeri so protivirusni programi, programi za varnostno kopiranje in programi za šifriranje ali stiskanje. Namenska programska oprema – računalniški program, izdelan za izvajanje nalog v korist končnega uporabnika. Primeri so podatkovna baza, poslovna programska oprema, urejevalniki besedila in računalniške igre.
4.2 Kriteriji glede na namen programske rešitve Namen programske rešitve nima neposrednega vpliva na odločitev o opustitvi razvoja lastne rešitve, je pa potrebno upoštevati, da je redko smiseln razvoj lastne rešitve za splošne namenske programske rešitve, kot so urejevalniki besedil, podatkovna baza, operacijski sistemi in programske rešitve za vodenje opravljenega dela. Če programska rešitev, o kateri ukinitve razmišljamo, rešuje nek splošen namen, za katerega obstajajo standardizirane rešitve, nadaljnji razvoj običajno ni smiseln. Težko bi upravičili interni razvoj orodja, kot je Word podjetja Microsoft, razen če ne želimo na tak način dosegati drugih strateških ciljev, kot v primeru izdelave programske rešitve OpenOffice s strani podjetja Sun.
4.3 Vrste programskih rešitev glede na tip licenciranja Glede na način licenciranja programske rešitve delimo na lastniške, zastonjske in odprtokodne. Lastniške programske rešitve (angl. proprietary software) – programske rešitve lahko uporabljamo samo proti plačilu, način uporabe je določen z licenčno pogodbo. Primer take programske rešitve je Microsoft Word. Zastonjske programske rešitve (angl. freeware software) – lastniške programske rešitve, ki jih lahko uporabljamo brez plačila, vendar pri uporabi lahko obstajajo omejitve uporabe. Primer take programske rešitve je Google Chrome. Odprta koda (angl. open source software) – odprta koda je način razvoja programske opreme, pri katerem lahko kodo brez plačila uporabljamo, predelamo in razširimo, vendar samo v skladu s tipom licence, v okviru katere je odprta koda razvita. Licenca ureja tudi pravila glede nadaljnje distribucije predelane kode (Open Source Initiative, 2016). Trenutno je s strani Open Source Initative odobrenih preko 70 različnih tipov licenc. Primer odprte kode je Mozzila Thunderbird.
31
4.4 Kriterij glede na tip licenciranja programske rešitve Če za izdelavo in vzdrževanje programske rešitve potrebujemo draga orodja, je lahko kriterij za opustitev programske rešitve tudi zamenjava ogrodja programske rešitve z odprtokodnimi rešitvami. Običajno imajo odprtokodne rešitve na voljo precej več dokumentacije, na voljo pa je tudi več kadra z ustreznimi znanji. Pri izbiri odprtokodnih rešitev je potrebna previdnost, pomembno je, da je izbrani odprtokodni projekt živ in da je dovolj razširjen. Odprtokodna rešitev, ki se ne uveljavi in se ne uporablja, bo slej ko prej zamrla, kar lahko pomeni veliko težavo za nadaljnji obstoj programske rešitve.
4.5 Vrste programskih rešitev glede na način izvajanja Programske rešitve se razlikujejo glede na način izvajanja oziroma glede na to, kje se izvajajo. Poznamo:
namizna programska oprema – programska rešitev, ki se samostojno izvaja v računalniku končnega uporabnika. Primer take programske rešitve je Microsoft Word;
strežniška programska oprema – programska rešitev, ki se izvaja v strežniku, storitve strežniške programske opreme so na voljo drugim računalnikom in njihovim uporabnikom. Primer take programske opreme je www.ebay.com;
vtičniki – dodatki k drugim programskim rešitvam, ki razširijo osnovne funkcionalnosti programske rešitve. Primer je vtičnik za pregled koledarja Lightning za Mozzila Thunderbird;
vgrajena programska oprema – namenska programska oprema, ki je že vgrajena v napravo. Primeri take programske opreme so programska oprema televizij, hladilnikov, avtomobilov;
skripti – kosi programske opreme, ki jih lahko izvajajo druge programske rešitve. Primer je zapis kode v jeziku JavaScript, koda je vključena v spletno stran, kodo izvaja spletni brskalnik.
4.6 Kriterij glede na način izvajanja programske rešitve Eden izmed kriterijev za ukinitev programske rešitve je lahko tudi želja po prehodu z namizne programske rešitve na spletno programsko rešitev. Če želi podjetje izvajati programsko rešitev v več različnih sistemih, je opcija, da se izdela eno spletno programsko rešitev, do katere lahko dostopamo iz različnih operacijskih sistemov.
32
4.7 Vrste programskih rešitev glede na število naročnikov
4.7.1 Kriteriji za prehod na serijsko rešitev Serijska programska oprema (angl. off the shelf software) je programska oprema s točno določenim namenom in z zaključenim naborom funkcionalnosti, ki naj bi ustrezale vsem uporabnikom. Tako programsko opremo lahko kupimo in takoj namestimo v svoje okolje. Prednosti takih rešitev so, da je cena relativno nizka, saj tako programsko opremo uporablja zelo veliko uporabnikov, zaradi količine uporabnikov pa je velika verjetnost, da takšna rešitev vsebuje vse funkcionalnosti, ki jih podjetje potrebuje. Predstavniki takih programskih rešitev so Microsoft Word, IBM DB2. Serijske rešitve običajno ne omogočajo posebnih razširitev na zahtevo kupca (Cooper, 2015). 4.7.1.1 Prednosti serijskih rešitev Ker se ista programska rešitev razvija za veliko različnih uporabnikov, je cena lahko bistveno nižja, kot če bi bila izdelana po meri za enega uporabnika. Dodatno lahko vsebuje veliko več funkcionalnosti, saj je pri velikem številu uporabnikov velika verjetnost, da se podobne zahteve po dodatnih funkcionalnostih pojavijo pri več različnih uporabnikih. Ker obstaja veliko število uporabnikov, je lahko na voljo več pomoči in izučenih kadrov, ki so seznanjeni z delovanjem programske rešitve. Dodatna prednost je, da so take rešitve hitreje na voljo za uporabo, saj se za izdelavo običajno porabi precej več časa kot za uvajanje že narejene rešitve. Prednosti so:
nizka cena;
velik nabor funkcionalnosti;
lahko dostopna podpora in literatura;
izmenjava datotek (primer so Wordove datoteke);
rešitev je takoj na voljo.
4.7.1.2 Slabosti serijskih rešitev Največja slabost serijskih rešitev je, da ne omogočajo konkurenčne prednosti, kot to velja za programske rešitve, kjer lahko z inovativnimi pristopi prehitimo konkurenco.
33
Slabosti so:
velika kompleksnost, saj običajno vsebuje veliko več funkcionalnosti, kot jo zares potrebuješ;
zaradi velike količine različnih uporabnikov so pri razvoju potrebni kompromisi, procesi zato niso optimalni glede na specifične zahteve;
zaradi kompleksnosti je potrebno veliko časa za priučitev uporabe;
prilagoditev delovnega procesa programski rešitvi;
manjkajoče funkcionalnosti, ki so specifične za potrebe nekega podjetja;
zahteva po dopolnitvi bo težko uslišana, saj je zaradi velike količine uporabnikov takih zahtev veliko;
nezadostna podpora v primeru težav;
ker imajo lahko druga podjetja isto programsko rešitev, je s tako programsko rešitvijo težko postati bolj konkurenčen.
4.7.2 Kriteriji za prehod na rešitev na zahtevo Rešitve na zahtevo (angl. custom software) so programske rešitve, ki so izdelane po meri za potrebe enega naročnika (Cooper, 2015). Pri takih rešitvah se programska rešitev popolnoma prilega poslovnim procesom podjetja. 4.7.2.1 Prednosti rešitev na zahtevo Ker so izdelane za enega naročnika, se programske rešitve lahko popolnoma prilegajo poslovnim procesom podjetja. Ena izmed prednosti je, da se med izdelavo programske rešitve običajno istočasno popiše in posodobi poslovne procese. Prednosti so:
izdelana je po meri za točno določene funkcionalnosti;
lahko se prilagodi obstoječi programski opremi, ki jo podjetje uporablja;
običajno jo uporabniki lažje uporabljajo, saj je prirejena obstoječim poslovnim procesom;
je bolj prilagodljiva, lažje se doda nove funkcionalnosti;
ob izdelavi programske rešitve se lahko izboljša poslovne procese;
če programska rešitev postane zanimiva tudi za druga podjetja, se jo lahko začne tržiti.
4.7.2.2 Slabosti rešitev na zahtevo Če podjetje z rešitvijo na zahtevo podpre poslovne procese, ki so standardni in že podprti v razpoložljivih rešitvah, je taka izbira lahko zelo draga investicija, ki ne pomeni konkurenčne
34
prednosti. Pri tem je bistveno, kakšen odnos se vzpostavi z izvajalcem rešitve na zahtevo. Pri takem sodelovanju gre vedno za dolgoročno povezovanje, pri čemer mora biti uspešnost projekta v obojestranskem interesu. Slabosti so:
lastništvo izvorne kode: če podjetje ni lastnik izvorne kode, lahko postane zelo odvisno od zunanjega izvajalca;
slaba izvedba: ker je samo en naročnik, lahko zmanjka sredstev za izpopolnjevanje;
cena investicije;
velika obremenjenost človeških virov pri izdelavi specifikacije;
pomanjkljiva dokumentacija;
težavno pridobivanje ustreznih kadrov.
5 KRITERIJI, VEZANI NA ZUNANJI ALI NOTRANJI RAZVOJ PROGRAMSKE REŠITVE
Podjetje lahko razvoj programske rešitve izvaja z lastnimi viri, lahko pa celotni razvoj ali dele razvoja prenese na enega ali več zunanjih izvajalcev. V primeru zunanjega izvajanja razvoja programske rešitve se sprejme odločitev, da se bo določeno vrsto dela prepustilo zunanjim strokovnjakom, ki so specializirani za opravljanje takega dela, in predvideva se, da ga lahko opravljajo veliko bolje kot lasten kader. Na ta način se v podjetju sprosti kader, ki se tako lahko osredotoči na osnovno dejavnost podjetja. S prenosom izvajanja razvoja programske rešitve na zunanjega izvajalca podjetje izgubi lastna znanja, posledično je tako odločitev kasneje zelo težko preklicati (Vodopivec, 2008). Odločitev o zunanjem izvajanju razvoja programske rešitve je strateškega pomena in ima dolgoročne posledice, zato je to odločitev, ki jo mora sprejeti vodstvo podjetja. Ko se podjetje odloča o ukinitvi razvoja programske rešitve, mora upoštevati, ali gre za notranji ali zunanji razvoj. V primeru zunanjega razvoja podjetje nima težav z zaposlenimi, lahko pa jih ima zaradi pogodbenih kazni, določenih v vzdrževalnih pogodbah. V nadaljevanju je predstavljeno, kaj pomeni zunanji in kaj notranji razvoj, v zadnjem delu pa so predstavljeni kriteriji, ki jih je potrebno upoštevati ob ukinitvi razvoja glede na njegov tip.
5.1 Zunanji razvoj programske rešitve Če del razvoja ali celotni razvoj programske rešitve prepustimo zunanjemu izvajalcu, lahko govorimo o zunanjem razvoju (angl. outsourcing). Razlogi za tako odločitev so različni in so opisani v nadaljevanju.
35
5.1.1 Prednosti zunanjega razvoja Strateške prednosti (Korber, 2002):
pridobitev novih znanj;
deljeno tveganje;
osredotočanje na ključne dejavnosti podjetja;
povečanje nadzora nad poslovanjem.
Tehnologija in pristopi k razvoju programske rešitve se izjemno hitro spreminjajo. Podjetja, katerih osnovna dejavnost ni vezana na informacijske tehnologije, zelo težko sledijo vsem tehnološkim spremembam in novostim. Če se podjetje odloči za sodelovanje z zunanjim izvajalcem, katerega osnovna dejavnost je informacijska tehnologija, ima na ta način možnost hitrejšega spoznavanja in uvajanja novih tehnologij. Ker zunanji izvajalci izvajajo storitve za več podjetij hkrati, lahko spoznanja in dobre prakse prenašajo med strankami, kar posledično zmanjša tveganje za naročnika zunanjega izvajanja. V primeru lastnega razvoja ene programske rešitve podjetje morebitnih dobrih praks, ki jih pridobi tekom razvoja, ne more izkoristiti tudi pri drugih projektih, dočim zunanji izvajalec dobre prakse uporabi pri več projektih. Podjetje se s prenosom razvoja na zunanjega izvajalca lahko osredotoči na svoje poslovanje, pri čemer mora biti pozorno, da na zunanjega izvajalca ne prenese inovativnega dela, ki je bistven za nadaljnjo rast podjetja. Ekonomske prednosti (Korber, 2002):
zmanjšanje in nadzor operativnih stroškov;
povečanje dobička in uspešnosti;
sprostitev investicij za druge namene;
povečanje tržnega deleža zaradi kapacitet zunanjega izvajalca;
transparentnost stroškov. Glavna motivacija za zunanje izvajanje je običajno poskus zmanjševanja operativnih stroškov. Predpostavka je, da lahko zunanji izvajalec isto storitev izvaja ceneje, saj stroške zniža z vlaganjem v razvoj znanja, ki ga lahko večkrat uporabi. Dodatna prednost je ta, da so stroški razvoja bolj jasno razvidni.
36
Organizacijske prednosti (Korber, 2002):
sprostitev internih virov za druge namene;
povečanje fleksibilnosti;
povečanje učinkovitosti in produktivnosti. Zunanji izvajalci lažje absorbirajo povečane obremenitve, ki lahko nastanejo zaradi spremenjenih okoliščin, kot so nepričakovane dodatne nove zahteve, spremembe zakonodaje, širitve na tuje trge. Zunanji izvajalci imajo prednost, saj imajo na voljo več ustreznih kadrov, kot jih ima na voljo podjetje, ki razvija eno samo lastno rešitev. Zunanji izvajalec lahko hitreje pridobi in izuči dodatne kadre.
5.1.2 Tveganje zunanjega razvoja Zunanji razvoj neizogibno prinese tudi slabosti, ki pa se jih da omiliti z ustreznim pristopom. Pri prehodu na zunanjega izvajalca je potrebno omejiti sledeča tveganja (Tompkins, 2016): Strateško tveganje:
predaja programske rešitve v zunanje izvajanje, ki predstavlja kompetenčno prednost;
cilji za prehod na zunanje izvajanje niso določeni;
niso vzpostavljeni učinkoviti kazalci uspešnosti, na podlagi katerih bi se lahko merilo zunanje izvajanje;
predaja v zunanje izvajanje brez celostne ocene stroškov notranjega razvoja;
vplivi prehoda na zunanje izvajanje na ostale funkcije podjetja niso preučeni;
prezgodnje razglašanje prehoda na zunanje izvajanje, še preden je jasen končni cilj in namen, nevarnost znižanja morale.
Tveganje izbora:
premajhna vključenost zaposlenih v izbor zunanjega izvajalca;
preslaba izobraženost lastnih kadrov za ustrezno oceno sposobnosti zunanjih izvajalcev;
preozek izbor kandidatov za zunanje izvajalce;
premajhno vedenje o kapacitetah zunanjega izvajalca;
uporaba neustrezne specifikacije pri dogovarjanju z morebitnimi kandidati za zunanje izvajanje;
izvedba procesa izbire na osebni in ne komercialni podlagi.
37
Tveganja pri implementaciji:
neustrezno opredeljena fleksibilnosti za primer povečanega obsega dela v pogodbi;
pogodba, ki omejuje nadaljnjo rast sodelovanja;
nerealistična pričakovanja glede časovne izvedbe projekta;
slabo načrtovan časovni prehod v produkcijo, ki ne opredeli zahtev do naročnika;
podcenjevanje časa, potrebnega za pogajanje glede pogodbe o zunanjem izvajanju;
nedefinirano obdobje prehoda za zaposlene. Organizacijska tveganja:
neustrezno proučen vpliv cene zunanjega izvajanja;
pomanjkljiva notranja komunikacija;
premalo vzpodbud za izboljševanje zunanjega izvajalca;
slabo vzpostavljena komunikacija z zunanjim izvajalcem;
slabo definirani postopki eskalacije problemov, redni sestanki, pregledi;
prevelika pričakovanja ob predaji v produkcijo.
5.1.3 Zunanji razvoj glede na število izvajalcev Razvoj programske rešitve se lahko:
izvaja v celoti pri enem zunanjem izvajalcu;
izvaja po delih pri več zunanjih izvajalcih;
izvaja po delih pri zunanjih izvajalcih in v lastnem razvoju.
Odločitev je odvisna od kompleksnosti programske rešitve. Če je programska rešitev obsežna in se jo da razbiti na več delov, je priporočljivo, da se razvoj posameznih delov ponudi različnim izvajalcem. Če razvoj celotne programske rešitve prevzame samo en izvajalec, lahko postane naročnik zelo ranljiv pri pogajanjih glede višine plačila, nudenja izboljšav in podobnem. V primeru več izvajalcev je potrebno veliko več usklajevanja, kar pa ni nujno slabo, saj lahko to pripelje do boljšega končnega izdelka.
5.1.4 Zunanji razvoj glede na lokacijo izvajanja Skrb za razvoj in izvajanje programske rešitve se lahko v celoti prepusti zunanjemu izvajalcu, kar pomeni, da se zunanjemu izvajalcu prepusti skrb za strojno opremo, razvoj programske opreme, tehnično podporo in izobraževanje. Druga možnost je, da se obdrži celoten nadzor nad razvojem in izvajanjem programske rešitve, v tem primeru zunanji izvajalec skrbi samo za ustrezno delovanje programske kode.
38
5.1.4.1 Razvoj in izvajanje v okolju naročnika Naročnik poskrbi za ustrezno razvojno, testno in produkcijsko okolje. Zunanji izvajalec priskrbi delujočo kodo. Izvajalec lahko dela na lokaciji pri naročniku ali preko spletne povezave. Pri tem načinu ima naročnik največjo kontrolo nad razvojem. Slabost je ta, da naročnik predpiše način razvoja, kar lahko izniči prednosti zunanjih izvajalcev, kot so pridobitev novih znanj razvoja. 5.1.4.2 Izvajanje v okolju naročnika, razvoj v okolju zunanjega izvajalca Naročnik poskrbi za ustrezno testno in produkcijsko okolje. Zunanji izvajalec mora poskrbeti za svoje razvojno okolje. Pri tem načinu naročnik obdrži nekaj tehničnega in nekaj vsebinskega znanja ter ima kontrolo nad predajanjem programske rešitve v produkcijo. 5.1.4.3 Razvoj in izvajanje v okolju zunanjega izvajalca Pri tej rešitvi naročnik prepusti celoten razvoj in izvajanje izvajalcu. Taka rešitev je ustrezna v primeru, da zunanji izvajalec isto rešitev nudi več naročnikom in je na trgu na voljo več ponudnikov s podobno rešitvijo. Primer take storitve je skrb za elektronsko pošto ali davčne blagajne. Pri taki rešitvi je poseben poudarek na dogovoru o lastništvu in dostopnosti do podatkov. Če podjetje svojo lastno obstoječo rešitev na tak način prepusti v zunanje izvajanje, je velika verjetnost, da bo podjetje izgubilo tehnično in poslovno znanje. 5.1.4.4 Izvajanje v okolju zunanjega izvajalca, razvoj v okolju naročnika Naročnik lahko prepusti skrb za infrastrukturo zunanjemu izvajalcu, pri čemer infrastruktura lahko ostane pri naročniku, lahko pa jo v celoti najame pri zunanjem izvajalcu. Na ta način podjetje obdrži razvoj programske rešitve in posledično poslovna znanja, izgubi pa določena infrastrukturna tehnična znanja.
5.2 Notranji razvoj Če razvoj programske rešitve podjetje izvaja z lastnimi kadri, lahko govorimo o notranjem razvoju (angl. in-house software). Če podjetje poleg lastnih kadrov najame tudi zunanje izvajalce specialiste, ki delajo na lokaciji pri naročniku, potem govorimo o notranjem razvoju z zunanjimi izvajalci (angl. insourcing). Tak pristop je smiseln, če želi podjetje obdržati popolno kontrolo nad strateško pomembnimi programskimi rešitvami. V nadaljevanju so predstavljene prednosti in slabosti (Williams, 2001).
39
5.2.1 Prednosti notranjega razvoja Poglavitna prednost notranjega razvoja je v tem, da ima podjetje nadzor nad celotnim potekom razvoja in lastništvo celotne programske rešitve. Na ta način lahko dosega boljše odzivne čase v primeru tehničnih težav in ima boljši pregled nad delovanjem celotnega sistema. Izvedba funkcionalnosti, ki je specifična samo za to podjetje, je v primeru notranjega razvoja cenejša. Prednosti so:
podjetje je v celoti lastnik programske rešitve;
pridobivanje znanja tekom izdelave programske rešitve;
hitrejši odzivni čas v primeru tehničnih težav;
notranje osebje ima boljši pregled nad delovanjem celotnega sistem;
lahko omogoči konkurenčno prednost pred tekmeci;
izdelava specifičnih funkcionalnosti.
5.2.2 Slabosti notranjega razvoja Ena izmed slabosti notranjega razvoja je, da podjetje potrebuje strokovnjake za vsa področja razvoja, ki pa jih ne more optimalno izrabiti. Podjetje, ki je specializirano samo za razvoj, ima običajno v izdelavi več različnih programskih rešitev, kjer lahko isto znanje večkrat uporabi. Ker lastni kader običajno skrbi za en produkt, le-ta težko sledi novim tehnologijam in novim metodologijam razvoja, saj podjetje nima dovolj strokovnjakov. Podjetja, ki se ukvarjajo samo z razvojem, običajno namenijo več denarja za izobraževanje o razvoju, kot podjetja, katerih temeljna dejavnosti ni razvoj programskih rešitev. Če se podjetje loti novega razvoja in za to še nima ustreznih znanj, bo za izdelavo programske rešitve potrebovalo veliko več časa in sredstev, kot bi jih potrebovalo za razvoj z zunanjimi izvajalci, ki že imajo ustrezna znanja. Za programske rešitve, ki so inovativne in bi bile tudi za zunanje izvajalce novost, je notranji razvoj primernejši, seveda pod pogojem, da ima podjetje na voljo zadostno število ustreznih kadrov. Slabosti so:
drago vzdrževanje;
zahteva veliko tehničnega osebja;
drago vzdrževanje tehničnega znanja;
počasna izvedba;
draga zamenjava tehnologije.
40
5.3 Diagram kriterijev glede na zunanji ali notranji razvoj programske rešitve
Ko se podjetje odloča o opustitvi programske rešitve, na odločitev vpliva tudi to, kdo razvija in vzdržuje programsko rešitev.
Slika 14: Kriteriji, ki jih je potrebno upoštevati glede na izvajalca razvoja
V primeru zunanjih izvajalcev je odločitev za prekinitev razvoja lažja, saj po opustitvi razvoja ni težav z odvečnimi delavci, vendar to še ne pomeni, da se lahko razvoj enostavno prekine. Če ima podjetje z zunanjim izvajalcem sklenjene visoke pogodbene kazni za primer predčasne prekinitve projekta, mora v takem primeru ugotoviti, kaj je optimalneje: da se ukinitev prestavi na ustreznejši datum ali da se prekinitev razvoja izvede takoj. Če je programska rešitev izdelana s pomočjo zunanjih izvajalcev, je potrebno ovrednotiti znanje, ki so ga zunanji izvajalci pridobili tekom razvoja, in ga, če je to možno, izkoristiti. Tudi v tem primeru je potrebno ustrezno načrtovanje ukinitve programske rešitve in uskladitev morebitnega prehoda zunanjih izvajalcev na nove projekte. Če se to ne upošteva,
41
lahko podjetje izgubi dragocen kader, v katerega je morda tekom razvoja ukinjene programske rešitve veliko vložilo. V primeru, da do ukinitve projekta z zunanjimi izvajalci pride, ker želi podjetje izdelati lastno programsko rešitev z lastnimi kadri, je pomembno, da se predvidi, kako bo podjetje sodelovalo z zunanjimi izvajalci v vmesnem obdobju, ko se bo izdelovalo novo programsko rešitev. Če podjetje ne sklene dogovora, ki bi bil sprejemljiv za obe strani, je lahko prehod na novo programsko rešitev precej boleč. Če razvoj izvajajo notranji razvijalci, je v primeru, da za odvečni kader znotraj podjetja ni možnosti za prerazporeditev na druge projekte, potrebno upoštevati stroške odpravnin.
Slika 15: Kriteriji, ki jih je potrebno upoštevati glede na lokacijo produkcijskega okolja
Odločitev za prekinitev razvoja programske
rešitve
Produkcijskookolje pri zunanjem
upravljalcu
Potrebno je upoštevati:
Koliko časa bo potreben dostop do podatkov ukinjene programske rešitve;
Kako se bo arhiviralo podatke;
Kako se bo uničilo podatke.
Potrebno je upoštevati:
Koliko časa bo potreben dostop do podatkov ukinjene programske rešitve;
Kako se bo arhiviralo podatke;
Ali se produkcijsko okolje lahko nameni za druge programske rešitve;
Ustrezna prekvalifikacija sistemskih inženirjev;
Izguba tehnološkega znanja.
Da Ne
Za vzdrževanje, uporabo in razvoj programske opreme je potrebno veliko tehničnega in vsebinskega znanja, ob ukinitvi razvoja pa se tako znanje lahko izgubi. Če je za podjetje
42
pomembno, da taka znanja ohrani, mora načrtovati, kako se bo po ukinitvi razvoja programske rešitve tako znanje ohranilo. Če se je programska rešitev izvajala v okolju zunanjega izvajalca, je potrebno ugotoviti, kako dolgo morajo biti podatki stare programske rešitve še na voljo in kako se bo, če je to potrebno, podatke arhiviralo. Poskrbeti je potrebno tudi za to, da se bodo občutljivi podatki pri zunanjem ponudniku ustrezno izbrisali oziroma uničili. Podobno je v primeru, ko se ukinja programsko rešitev, ki se izvaja znotraj podjetja, razlika je v tem, da vsaj strojna oprema običajno ostane v podjetju in lahko za določeno obdobje še naprej gosti programsko rešitev. Obdobje, po katerem se programska rešitev dokončno ugasne, je v tem primeru lahko precej daljše. Tudi pri notranjem razvoju je potrebno razmisliti, kako se bo podatke arhiviralo in kaj se bo naredilo s strojno opremo, ko ne bo več v uporabi. Ob ukinitvi starejših sistemov je potrebno razmisliti o prekvalifikaciji sistemskih inženirjev ali morebitnem odpuščanju odvečnih delavcev. Če podjetje ob ukinitvi programske rešitve ne bo več potrebovalo določenih tehnoloških znanj, vendar načrtuje, da bi jih v bodočnosti ponovno potrebovalo, lahko temu ustrezno priredi datum ukinitve programske rešitve.
6 KRITERIJI, VEZANI NA CENO RAZVOJA Če podjetje oceni, da je cena razvoja programske rešitve previsoka, ima več možnosti:
zamenja programsko rešitev s kupljeno rešitvijo, če le-ta obstaja;
predela programsko rešitev v produkt;
skupni razvoj programske rešitve;
niža stroške razvoja s spremembo metodologije razvoja.
6.1 Kriteriji zamenjave programske rešitve s kupljeno rešitvijo Pred dokončno odločitvijo o zamenjavi lastne programske rešitve s kupljeno rešitvijo je potrebno raziskati, ali bo nova rešitev zares pokrila vse potrebe, ali bo omogočila nadaljnji razvoj podjetja in ali je nova rešitev dolgoročno res cenejša. Pri kupljenih rešitvah so izdelave dodatnih funkcionalnosti, pisanih na kožo podjetja, bistveno dražje kot izdelava dodatne funkcionalnosti na lastni programski rešitvi. Pomembno je tudi, ali bo nova programska rešitev enako uporabna kot obstoječa, saj splošne rešitve ne morejo biti popolnoma prilagojene poslovnim procesom podjetja. Običajno je potrebno ob zamenjavi programske rešitve spremeniti tudi način dela znotraj podjetja. Takšne spremembe niso nujno slabe, saj lahko z novo programsko rešitvijo uvedemo tudi boljše prakse, je pa potrebno vnaprej predvideti morebitne spremembe poslovnih procesov.
43
Kriteriji zamenjave programske rešitve s kupljeno rešitvijo:
ali nova programska rešitev nudi vse potrebne funkcionalnosti;
ali je nova programska rešitev enako uporabna kot obstoječa;
kakšna je cena nadgradenj;
kakšna je cena vzdrževanja;
kakšne so možnosti razširitve osnovnih funkcionalnosti;
ali se da programsko rešitev nadgraditi z lastnimi kadri.
6.2 Kriteriji predelave programske rešitve v produkt Znotraj različnih podjetij se s programsko rešitvijo pogosto rešuje iste težave in podpira enake poslovne procese, kar pomeni, da je lahko vsaka programska rešitev, razvita znotraj podjetja, potencialno zanimiva tudi za druga podjetja. Če podjetje oceni, da je njihova programska rešitev tržno zanimiva in bi na ta način porazdelilo stroške razvoja, lahko programsko rešitev predela v produkt in ga ponudi na trgu (Gandham, 2014). Predpogoj je testiranje trga, preverba, ali obstaja povpraševanje po takemu tipu produkta. Če povpraševanje obstaja, se poišče in stopi v kontakt z morebitnimi strankami. Na podlagi pogovorov z morebitnimi strankami se lahko določi okvirno ceno, ki bi jo bile stranke pripravljene plačati za tak produkt. Pri izdelavi poslovnega načrta je potrebno upoštevati stroške, ki so povezani s predelavo programske rešitve v produkt, saj je strošek izdelave programske rešitve po meri in programske rešitve, ki se jo ponudi na trgu, precej drugačen. Pri predelavi programske rešitve za trg je običajno potrebna izboljšava in prilagoditev uporabniškega vmesnika. Če gre za množično programsko rešitev, je potrebno računati na večja vlaganja v oglaševanje. Ker bo programska rešitev delovala v različnih sistemih pri različnih uporabnikih, je običajno potrebna izboljšava arhitekture in robustnosti programske rešitve, računati je potrebno na poenostavitev namestitve programske rešitve. Pri rešitvah, ki so narejene po meri, pogosto pride do kompromisnih odločitev glede cene in funkcionalnosti na račun funkcionalnosti, kar je potrebno ob prehodu programske rešitve na trg popraviti. Če gre za množično programsko rešitev z veliko uporabniki, je potrebno razmišljati o izgradnji podpore naročnikom. Potrebno je izdelati ustrezno dokumentacijo. Primer podjetja, ki je pričelo z izdelavo programske rešitve za končno stranko, kasneje pa jo je predelalo v uspešen produkt, je podjetje Dectar. Za končnega uporabnika so izdelali programsko rešitev, ki nudi podobne funkcionalnosti, kot jih nudi Uber za prevoz ljudi. Ko so programsko rešitev izdelali, so ugotovili, da ima veliko drugih podjetij enake potrebe, kar pomeni, da bi lahko programsko rešitev ponudili kot storitev kateri koli dejavnosti.
44
Programsko rešitev so predelali v platformo, ki se lahko prilega kateremu koli poslovnemu modelu tipa Uber. Tako so od leta 2014 do danes zrastli v podjetje z več kot sto zaposlenimi. Drugi primer je podjetje Tempo, ki je za lastne potrebe razvilo programsko rešitev, ki razširi funkcionalnosti programske rešitve JIRA podjetja Atlassian. Izdelalo je razširitev za beleženje in spremljanje opravljenega dela. Programska rešitev JIRA je že v osnovi vsebovala možnost beleženja ur, prav tako je v tem času že obstajalo več drugih rešitev, ki so nudile podobno funkcionalnost. V podjetju Tempo so bili prepričani, da je njihova rešitev boljša in da bi z njihovo rešitvijo lahko tudi drugim podjetjem pomagali pri izboljšanju učinkovitosti in vidnosti opravljenega dela. Imeli so prav, saj je podjetje v osmih letih zraslo na več kot osemdeset zaposlenih, njihov produkt uporablja več kot 8.500 podjetij v več kot sto različnih državah. Vse skupaj pa se je začelo z reševanjem interne potrebe po boljši preglednosti porabljenega časa. Odločilno je bilo, da je njihovo vodstvo pravočasno prepoznalo potencial njihove interne rešitve (Tempo). Kriteriji za predelavo programske rešitve v produkt so:
obstajajo potencialne stranke;
obstajajo konkurenčne programske rešitve;
programska rešitev je boljša od konkurence;
programsko rešitev je možno predelati v produkt;
podjetje je pripravljeno vlagati v programsko rešitev;
podjetje je pripravljeno tržiti produkt.
6.3 Kriteriji predaje programske rešitve v skupni razvoj Če podjetje ugotovi, da je interni razvoj programske rešitve drag in prepočasen in da bi z združitvijo moči pri razvoju z drugimi podjetji koristilo svojemu osnovnemu poslanstvu, lahko sproži iniciativo skupnega razvoja programske rešitve. Primer skupnega razvoja je razvojno okolje Eclipse, ki je nastalo na podlagi IBM-ovega orodja VisualAge. Leta 2001 je bil ustanovljen konzorcij, katerega naloga je bila izdelava odprtokodnega razvojnega okolja Eclipse. Ustanovni člani so bila podjetja Borland, IBM, Merant, QNX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft in WebGain. Vsako izmed ustanovnih podjetij je že imelo lastne rešitve, vse pa so imele pomanjkljivosti. Leta 2004 je bila ustanovljena fundacija Eclipse (Eclipse). Kriterija predaje programske rešitve v skupni razvoj:
razvoj je preobsežen za eno samo podjetje;
obstaja interes za skupni razvoj.
45
7 KRITERIJI, VEZANI NA TEHNOLOGIJO PROGRAMSKE REŠITVE
Pomemben kriterij za nadaljevanje razvoja programske rešitve je, ali je programska rešitev tehnološko ustrezna. Če je programska rešitev zastarela in za svoje delovanje potrebuje zastarelo okolje, imamo lahko težave s podporo produkcijskega okolja. Če programska rešitev ne deluje v novejših verzijah baze ali operacijskih sistemov, ima podjetje lahko težave s pridobivanjem podpore s strani proizvajalcev opreme. Podjetja, ki izdelujejo operacijske sisteme ali podatkovne baze, nudijo podporo za starejše verzije svojih produktov omejeno časovno obdobje, nekje do deset let. Dodatna težava z zastarelimi tehnologijami je, da ni na voljo novih, dodatnih kadrov, saj se mladi običajno izogibajo zastarelim tehnologijam. Tak primer je pomanjkanje programerjev v programskem jeziku COBOL, s katerim se soočajo v marsikaterem podjetju. Če je programska rešitev razvita s pomočjo tehnologije, ki ne omogoča skalabilnosti, je edina rešitev opustitev in izdelava nove programske rešitve. Do tega lahko pride v podjetjih, ki hitro rastejo. Ko ima podjetje majhno število zaposlenih in majhno število strank, lahko programska rešitev deluje brez težav, ko pa podjetje zraste, lahko zaradi neustrezne tehnologije in arhitekture programska rešitev preneha delovati. V takem primeru je potrebno zamenjati tehnologijo, kar običajno pomeni, da se staro programsko rešitev zavrže in naredi novo. Kriteriji, vezani na tehnologijo programske rešitve, so:
prenova programske rešitve je izvedljiva;
na voljo so kadri, ki imajo ustrezna znanja;
na voljo je ustrezna strojna oprema;
na voljo je ustrezna programska oprema;
obstaja podpora za strojno in programsko opremo, ki jo programska rešitev potrebuje;
skalabilnost programske rešitve.
8 RAZVRSTITEV KRITERIJEV Kriteriji, ki vplivajo na odločitev o opustitvi razvoja programske rešitve, ki sem jih našel s pomočjo literature in so opisani v predhodnih poglavjih, razločno vplivajo na tri osnovne kriterije. V tabeli 1 (Razvrstitev kriterijev) sta zapisana kriterij in opredelitev, na kateri osnovni kriterij posamezen kriterij vpliva.
46
Tabela 1: Razvrstitev kriterijev
Kriteriji
Fu
nk
cion
aln
osti
Kva
litet
a
Cen
a
Uporabnost
Skladnost s standardi in zakonodajo Da Da
Enostavnost in jedrnatost Da
Celovitost Da
Razumljivost, preglednost in strukturiranost Da
Opremljenost z dokumentacijo (priročniki) Da
Povezljivost Da Da
Uporabniku prijazen in estetski uporabniški vmesnik Da
Ocena izvedljivosti naloge Da
Težave z uporabnostjo Da
Čas za izvedbo naloge Da
Stopnja zadovoljstva ob izvedbi naloge Da
Stopnja zadovoljstva po testiranju uporabnosti Da
Napake uporabe Da
Pričakovanje uporabnika Da
Število klikov Da
Merjenje uspešno izvedenih transakcij Da
Skupna ocena uporabnosti Da
Zanesljivost
Natančnost izračuna in prikaza Da
Konsistentnost baze podatkov Da
Delovanje brez programskih napak Da
Ponovljivost operacije Da
Ekonomičnost
Cena za izdelavo dodatnih funkcionalnosti Da
Cena servisiranja in vzdrževanja Da Da
Hitrost izvajanja operacij v primeru dela brez računalniške podpore Da Da Da
Zasedba diskovnega prostora Da Da
Zahtevnost v odnosu do strojne opreme Da Da
Varnost
Stabilnost baze podatkov in programske opreme Da
Možnost varnostnih kopij, reševanje podatkovnih katastrof Da Da Da
Izvajanje nadzora nad sistemi in uporabniki Da Da Da
Zaščita pred namernimi in nenamernimi napakami in vdori Da Da Da
Zaupnost Da Da Da
Se nadaljuje
47
Nadaljevanje s prejšnje strani
Kriteriji
Fu
nk
cion
aln
osti
Kva
litet
a
Cen
a
Integriteta Da Da Da
Avtentikacija Da Da Da
Avtorizacija Da Da Da
Razpoložljivost Da Da Da
Nezatajljivost Da
Da
Učinkovitost
Večopravilnost Da Da
Hitrost procesiranja Da Da
Zasedba pomnilnika Da Da
Podpora različnim operacijskim sistemom Da Da Da
Vzdrževanje
Prilagodljivost in prenosljivost Da Da
Enostavnost namestitve Da Da Da
Enostavnost detekcije napak Da Da Da
Neodvisnost od strojne opreme Da Da Da
Ustrezna tehnična dokumentacija Da Da
Možnost administriranja Da Da Da
Razvoj
Ustreznost/reference uporabljenih tehnologij Da Da Da
Ustreznost razvojnih orodij Da Da
Razvojni proces Da Da Da
Vlaganje v razvoj Da Da Da
Komunikacija z uporabniki Da Da Da
Pomoč uporabnikom Da Da
Možnost nadgrajevanja Da Da Da
Vsebina
Skladnost s poslovnimi procesi Da
Pokritost poslovnih procesov Da
Ustrezna predstavitev poslovnih procesov Da
Metodologija razvoja
Uporaba orodij za spremljanje razvoja programske rešitve Da Da Da
Frekvenca predaje novih verzij Da Da Da
Ustrezna uporaba orodij za hranjenje kode Da Da
Ustrezno definiran postopek za predajo verzije Da Da
Uporaba orodij za sprotno preverjanje, prevajanje in testiranje kode Da Da
Sprotna gradnja in širjenje testov Da Da
Se nadaljuje
48
Nadaljevanje s prejšnje strani
Kriteriji
Fu
nk
cion
aln
osti
Kva
litet
a
Cen
a
Vključitev uporabnikov v razvojni proces Da Da Da
Definirani postopki pregledovanja opravljenega dela Da Da Da
Uporaba orodij za pregledovanje in komentiranje kode Da Da
Uporaba orodij za preverjaje pokritosti kode Da Da
Kriterij glede na tip licenciranja programske rešitve
Obstaja odprtokodna rešitev Da Da Da
Kriterij glede na način izvajanja programske rešitve
Način izvajanja programske rešitve Da
Kriterij za prehod na serijsko rešitev
Obstaja serijska rešitev Da Da Da
Kriteriji za prehod na rešitev na zahtevo
Popolnoma se prilega poslovnemu procesu Da Da
Izdelana po meri za točno določene funkcionalnosti Da Da
Lahko se prilagodi obstoječi programski opremi, ki jo podjetje uporablja Da Da
Lažje dodajanje novih funkcionalnosti Da Da
Ob izdelavi programske rešitve se lahko izboljša poslovne procese Da
Če programska rešitev postane zanimiva tudi za druga podjetja, se jo lahko začne tržiti
Da Da Da
Lastništvo izvorne kode Da
Pomanjkljiva dokumentacija Da
Težavno pridobivanje ustreznih kadrov
Da
Zunanji razvoj
Pridobitev novih znanj Da Da
Deljeno tveganje Da Da Da
Osredotočanje na ključne dejavnosti podjetja Da Da
Povečanje nadzora nad poslovanjem Da
Zmanjšanje in nadzor operativnih stroškov Da
Sprostitev investicij v druge namene Da
Transparentnost stroškov Da
Sprostitev internih virov za druge namene Da
Povečanje fleksibilnosti Da Da
Povečanje učinkovitosti in produktivnosti Da Da Da
Predaja programske rešitve v zunanje izvajanje Da Da
Zunanji razvoj glede na število izvajalcev
Izvaja se v celoti pri enem zunanjem izvajalcu Da Da
Izvaja se po delih pri več zunanjih izvajalcih Da Da
Se nadaljuje
49
Nadaljevanje s prejšnje strani
Kriteriji
Fu
nk
cion
aln
osti
Kva
litet
a
Cen
a
Izvaja se po delih pri zunanjih izvajalcih in v lastnem razvoju Da Da
Zunanji razvoj glede na lokacijo izvajanja
Razvoj in izvajanje v okolju naročnika
Da
Izvajanje v okolju naročnika, razvoj v okolju zunanjega izvajalca
Da
Razvoj in izvajanje v okolju zunanjega izvajalca
Da
Izvajanje v okolju zunanjega izvajalca, razvoj v okolju naročnika Da
Notranji razvoj
Podjetje je v celoti lastnik programske rešitve Da
Pridobivanje znanja tekom izdelave programske rešitve Da
Hitrejši odzivni čas v primeru tehničnih težav Da Da
Notranje osebje ima boljši pregled nad delovanjem celotnega sistem Da Da Da
Lahko omogoči konkurenčno prednost pred tekmeci Da Da
Izdelava specifičnih funkcionalnosti Da
Drago vzdrževanje Da
Zahteva veliko tehničnega osebja Da Da
Drago vzdrževanje tehničnega znanja Da Da
Počasna izvedba Da Da
Draga zamenjava tehnologije Da Da Da
Kriteriji zamenjave programske rešitve s kupljeno rešitvijo
Ali nova programska rešitev nudi vse potrebne funkcionalnosti Da
Ali je nova programska rešitev enako uporabna kot obstoječa Da Da
Kakšna je cena nadgradenj Da
Kakšna je cena vzdrževanja Da
Kakšne so možnosti razširitve osnovnih funkcionalnosti Da Da
Ali se da programsko rešitev nadgraditi z lastnimi kadri Da Da
Kriteriji predelave programske rešitve v produkt
Obstajajo potencialne stranke Da
Obstajajo konkurenčne programske rešitve Da
Programska rešitev je boljša od konkurence Da Da
Programsko rešitev je možno predelati v produkt Da Da
Podjetje je pripravljeno vlagati v programsko rešitev Da
Podjetje je pripravljeno tržiti produkt Da Da Da
Kriteriji predaje programske rešitve v skupni razvoj
Razvoj je preobsežen za eno samo podjetje Da Da Da
Obstaja interes za skupni razvoj Da Da Da
Kriteriji, vezani na tehnologijo programske rešitve
Se nadaljuje
50
Nadaljevanje s prejšnje strani
Kriteriji
Fu
nk
cion
aln
osti
Kva
litet
a
Cen
a
Prenova programske rešitve je izvedljiva Da Da Da
Na voljo so kadri, ki imajo ustrezna znanja
Da
Na voljo je ustrezna strojna oprema Da Da
Na voljo je ustrezna programska oprema Da Da
Obstaja podpora za strojno in programsko opremo, ki jo programska rešitev potrebuje
Da Da
Skalabilnost programske rešitve Da Da
9 IZGRADNJA DIAGRAMA POTEKA
9.1 Diagram poteka Diagram poteka (angl. flowchart) je diagram za prikaz možnih poti skozi sistem oziroma program in predstavlja model rešitve za dani problem. Uporablja se za analizo, načrtovanje, dokumentacijo ali urejanje procesov v računalništvu, fiziki, medicini, matematiki in še na mnogih drugih področjih. Prvo metodo za strukturirani prikaz procesa sta predstavila Frank in Lillian Gilberth že leta 1921. Leta 1949 je Douglas Hartree predstavil, kako sta Herman Goldstine in John von Neumann razvila diagram poteka za razvoj programov. Od takrat naprej so bili diagrami poteka zelo pogosti za opisovanje računalniških programov, njihova uporaba pa se je z uvedbo tretje generacije programskih jezikov (Flowchart) začela manjšati v 70-ih letih. Tudi danes so diagrami pogosta oblika prikaza algoritmov. Moderne tehnike, kot so diagrami UML (Unified Modeling Language), lahko štejemo med razširitve diagramov poteka. Grobo lahko diagrame poteka delimo v štiri skupine:
dokumentni diagram poteka – prikazuje potek dokumentov skozi sistem;
podatkovni diagram poteka – prikazuje potek podatkov skozi sistem;
sistemski diagram poteka – prikazuje potek skozi celoten sistem;
programski diagram poteka – prikazuje potek programa znotraj sistema.
51
Za predstavitev diagrama poteka so običajno uporabljeni naslednji simboli:
Tabela 2: Osnovni simboli diagrama poteka
Simbol Ime Opis
Smer poteka Puščica, ki se začne pri enem in konča pri drugem
simbolu, predstavlja njuno povezavo in smer prehajanja med njima.
Proces Pravokotnik predstavlja proces, prikazuje neko dejavnost.
Odločitev Romb predstavlja točko, kjer je potrebna odločitev, različne odločitve vodijo v različne smeri izvajanja algoritma, ki so ponazorjene z dvema ali več izhodnimi puščicami.
Terminal Zaobljen pravokotnik predstavlja začetek ali konec procesa.
Vhod/izhod Predstavlja prejemanje ali prikaz podatkov.
Povezava iz druge strani
Krog predstavlja povezavo iz druge strani.
Povezava na drugo stran
Predstavlja povezavo na drugo stran.
V naprej določen proces
Dvojni pravokotnik predstavlja kompleksen proces, ki je lahko podrobneje predstavljen na ločenem diagramu poteka.
Vir: Flowchart Symbols, b. l.
Na voljo je veliko različnih programskih orodij za izdelavo diagramov poteka, nekatera orodja omogočajo tudi direktno izdelavo programske kode. Na slikah 16 in 17 sta prikazana dva diagrama poteka, prvi predstavlja grafično predstavitev enostavne kode za izpis števil od 0 do 99. Programska koda: for (int i = 0; i < 100; i++) { System.out.println(i); }
52
Slika 16: Primer enostavnega algoritma za izpis številk od 0 do 99
Začetek
I = 0
I = I + 1
Izpiši I
I > 100
Ne
KonecDa
Predstavljena je zanka, ki v vsakem koraku poveča število i za 1 in ga izpiše. Zanka se izvaja, dokler števec ne doseže številke 100. Na drugem diagramu je predstavljen potek prihoda in obravnave pacienta pri zdravniku.
Slika 17: Primer diagrama poteka sprejema pacienta pri zdravniku
Prihod pacienta
Je pacient že v sistemu
Prijava pacienta
Ne
Je sestra na voljo
Da
Čakalnica
Ne
Pregled krvi, teže, pritiska,
urinaDa
Je zdravnik na voljo
Čakalnica
Ne
Pregled pri zdravnikuDa
Potrebno dodatno
naročanje
Potrebna zdravila
Ne
Izdaja novega termina
Odhod pacienta
Da
Izdaja recepta
Ne
Da
Vir: Medical Services Flowchart, b. l.
53
Začetek diagrama je prihod pacienta v zdravstveni dom, najprej se preveri, ali je pacient naročen, če ni, se ga prijavi in napoti k medicinski sestri. Dokler medicinska sestra ni na voljo, pacient čaka v čakalnici. Ko je sestra na voljo, le-ta opravi osnovne preiskave, nato gre pacient v čakalnico, kjer čaka na zdravnika. Zdravnik določi, ali so potrebni nadaljnji pregledi in ali bo predpisal pacientu ustrezna zdravila. S tem diagramom je opisan potek obravnave pacienta pri zdravniku. Iz predstavljenih primerov je razvidno, da se z diagrami poteka lahko opiše zelo različne procese.
9.2 Izdelava odločitvenega diagrama opustitve razvoja programske rešitve
Odločitveni diagram opustitve razvoja programske rešitve je izdelan na podlagi prebrane teorije in primerov opustitve in nadaljevanja lastnega razvoja. Predstavljen je s pomočjo diagrama poteka. Ideja je, da s pomočjo prehoda preko odločitvenega diagrama ugotovimo, ali je nadaljnji razvoj še smiseln, in če ni, kaj je potrebno spremeniti, da bo. V diagramu niso uporabljeni vsi predhodno opisani kriteriji, na primer kriterij »kvaliteta« vključuje vse kriterije, za katere smo v tabeli 1 označili, da imajo vpliv na kvaliteto. Diagram se prične z vprašanjem, kaj nas pri programski rešitvi najbolj moti (ali je to cena, kvaliteta ali pomanjkljive funkcionalnosti), v nadaljevanju pa so uporabljeni kriteriji, ki so relevantni glede na predhodne odgovore. Seznam uporabljenih kriterijev:
kvaliteta;
funkcionalnosti;
visoki stroški razvoja/vzdrževanja;
izvedljivost nadgradenj;
pomanjkanje kadrov;
napake po nadgradnjah;
zastarela tehnologija;
obstoj alternativnih programskih rešitev;
ali programsko rešitev zares potrebujemo;
ocena potrebnosti programske rešitve;
izvedljivost trženja programske rešitve;
prehod na odprto kodo;
pregled funkcionalnosti alternativnih programskih rešitev;
ocena stroškov alternativnih programskih rešitev;
razširljivost alternativnih programskih rešitev.
54
Po prehodu preko diagrama lahko pridemo do naslednjih odgovorov:
nadaljuj razvoj programske rešitve;
za nadaljnji razvoj je potrebno zagotoviti ustrezne kadre;
zamenjava nadgraditev metodologije;
potrebno je začeti postopek za izdelavo nove programske rešitve;
potrebno je izvesti prenovo programske rešitve;
opusti razvoj;
trženje lastne rešitve;
znižanje stroškov razvoja s predajo programske rešitve v odprto kodo;
nadaljuj razvoj programske rešitve, potrebno je spremljanje alternativnih rešitev;
zamenjava lastne rešitve s kupljeno rešitvijo. Če je odgovor tak, da lahko upoštevanje odgovora vpliva na odgovor na začetno vprašanje, se moramo ponovno sprehoditi preko celotnega diagrama z upoštevanjem novega stanja. Če mislimo, da je pomanjkljivost funkcionalnosti poglavitna težava in nato s pomočjo diagrama ugotovimo, da je edina rešitev za izboljšanje funkcionalnosti pridobitev dodatnih kadrov, in če vemo, da lahko dodatni kadri bistveno vplivajo na ceno programske rešitve, to lahko pomeni, da pomanjkljivost funkcionalnosti ni več poglavitna težava, temveč je po novem poglavitna težava cena programske rešitve. Ob ponovnem prehodu preko odločitvenega diagrama z upoštevanjem, da je poglavitna težava cena, lahko ugotovimo, da je dejanski odgovor na vprašanje glede smiselnosti nadaljnjega razvoja naše programske rešitve ukinitev in zamenjava lastne rešitve s kupljeno rešitvijo. Če pa po ugotovitvi, da potrebujemo dodatne kadre, ocenimo, da se cena ni bistveno povečala in da cena programske rešitve ni ovira nadaljnjega razvoja, ponovni prehod preko diagrama ni potreben. Po prehodu diagrama se je vedno potrebno vprašati, ali bi z upoštevanjem odgovora morda vplivali na začetno vprašanje diagrama. Odločitveni diagram je izdelan s programsko rešitvijo Visio podjetja Microsoft in je razdeljen na tri sklope. Prvi sklop pokriva vprašanja glede nadaljnjega razvoja (slika 18), drugi sklop preverja alternativne programske rešitve (slika 19), tretji sklop pa podaja predloge, kako izboljšati metodologijo razvoja (slika 20).
55
Slika 18: Odločitveni diagram opustitve razvoja programske rešitve – 1. del
Ali obstaja dobavljiva
alternativna programska
rešitev
Da
Jenadgradnja programske
rešitve enostavno izvedljiva
Da
Programsko rešitev se težko
nadgradizaradi
Zastarele tehnologije
Pomankanje kadrov
Programskarešitev imatežave s/z
Visokimi stroški razvoja/vzdrževanjaKvaliteto
Pomanjklivo funkcionalnostjo
Ne
Napak po nadgradnjah
Ali lahkopodjetje deluje
brez programske rešitve
Da
Ne
Kaj je dražje?
Vzdrževanje programske rešitve
Ali je posodobitev
tehnologijeizvedljiva
Delo brez programske rešitve
Ne
Da
Začetek
Nadaljuj razvoj programske rešitve
Za nadaljnji razvoj je potrebno
zagotoviti ustrezne kadre
Opusti razvoj
Potrebno je izvesti prenovo, z odlašanjem
strošek prenove narašča
Potrebno je začeti postopek
za izdelavo nove programske rešitve, čakanje stroške nove programske rešitve
povečuje
Strateška odločitev
Trženje lastne rešitve
Odprta koda
Opusti razvojTrženje lastne
rešitve
Znižanje stroškov razvoja s predajo programske rešitve v
odprto kodo
Povezava 1
Zamenjava programske rešitve
Stroške lahko nižamo s/z
Posodobitev programske rešitve
Sprememba metodologije
Ne
Zamenjava, nadgraditev
metodologije
Povezava 2
56
Slika 19: Odločitveni diagram opustitve razvoja programske rešitve – 2. del
Ali nova programska rešitevpokriva obvezno funkcionalnost
obstoječe rešitve
Ali seda alternativno
programsko rešitev ustrezno razširiti
Ne
Da
Izvedi analizo stroškov
kupljene rešitve napram
lastnemu razvoju
Lastnirazvoj bistveno
cenejši
Ne
Da
Da
Strateška odločitev
Opustitev razvoja
Odprta koda
Trženje lastne rešitve
Strateška odločitev
Odprta koda
Nadaljnji razvoj
Zamenjava lastne rešitve s
kupljeno rešitvijo
Trženje lastne rešitve
Znižanje stroškov razvoja s predajo
programske rešitve v odprto
kodo
Trženje lastne rešitve
Stara programska rešitevše naprej pokriva
funkcionalnosti, ki jih nova ne pokriva
Ne
Je izvedljivo
Ni izvedljivo
Strateška odločitev
Odprta koda
Nižanjestroškov
z zamenjavometodologije
Trženje lastnerešitve
Nadaljuj razvoj programske rešitve,
potrebno spremljanje
alternativnih rešitev
Povezava 1
Zamenjava, nadgraditev
metodologije
Povezava 2
57
Slika 20: Odločitveni diagram opustitve razvoja programske rešitve – 3. del
Zamenjava/dopolnitev
metodologijePodjetje nima ustreznih znanj Podjetje ima ustrezna znanja
Strateška odločitev
Novi zaposleni Izobraževanja
Sodelovanje z zunanjim izvajalcem
Zaposli se osebe z ustreznimi
znanji
Sodeluje se z zunanjim
izvajalcem, ob sodelovanju se
pridobi/prekopira
ustrezna znanja
konferenceseminarjišolanjetreningi
Dogovor o korakih
spremembe metodologije
Povezava 2
9.3 Testiranje diagrama Diagram bom testiral na dveh primerih. Prvi je odločitev slovenskega zavarovalniškega podjetja o opustitvi lastne programske rešitve, ki jo je razvijala do leta 2000. Drugi primer je primer opustitve lastne rešitve za vodenje ur v podjetju Marand.
9.3.1 Opustitev razvoja programske rešitve za vodenje življenjskih polic v slovenskem zavarovalniškem podjetju
Leta 2000 je imelo podjetje težave z obstoječo rešitvijo za spremljanje življenjskih zavarovanj. Težave je imelo tako s funkcionalnostmi kot tudi s kvaliteto lastne rešitve. Prišli so do ugotovitve, da je njihova rešitev zastarela in da nimajo ustreznih kadrov, s katerimi bi lahko razvili novo programsko rešitev. Rešitev, za katero so se odločili, je bila, da bodo poiskali zunanje partnerje, s katerimi bodo skupaj razvili novo rešitev. Takratno odločitev bom v nadaljevanju preveril z diagramom (slike 21, 22 in 23). Najprej preverimo poglavitno težavo, to je težavo s kvaliteto. Potek odločanja bi bil tak, kot je predstavljen na sliki 21.
58
Najprej bi ugotovili, da je glavna težava kvaliteta, za izboljšavo kvalitete je potrebna sprememba metodologije, ker podjetje ni imelo ustreznih znanj, nas diagram vodi do naslednjih treh možnih odgovorov: da se mora podjetje povezati z zunanjim izvajalcem, da mora vlagati v dodatno izobraževanje obstoječih zaposlenih ali pa da se dodatno zaposli kader, ki ima ustrezna znanja. Za vsak odgovor moramo preveriti, kakšen je vpliv odgovora na našo prvotno težavo. Če dodatne zaposlitve vplivajo na to, da je cena glavna težava, potem gremo ponovno preko odločitvenega diagrama s poudarkom na težavi s ceno.
Slika 21: Odločitev glede nadaljevanja razvoja programske rešitve za življenjska zavarovanja zaradi težav s kvaliteto
V drugi iteraciji bi z odločitvenim diagramom testirali težave s pomanjkljivimi funkcionalnostmi, potek odločanja bi bil tak, kot je na sliki 22. Najprej bi ugotovili, da nadgradnja programske rešitve ni enostavno izvedljiva, nato bi poiskali vzrok, nakar bi ugotovili, da je nadgradnja težko izvedljiva zaradi zastarele tehnologije. Ker posodobitev tehnologije ni bila izvedljiva, je bilo potrebno pričeti postopek za izdelavo nove programske rešitve.
59
Slika 22: Odločitev glede nadaljnjega razvoja programske rešitve za življenjska zavarovanja zaradi težav s pomanjkljivimi funkcionalnostmi
Programska rešitev ima pomanjkljivo funkcionalnost
Nadgradnja programske rešitve ni enostavno izvedljiva
Programska rešitev se težko nadgradi zaradi zastarele
tehnologije
Posodobitev tehnologije ni izvedljiva
Potrebno je pričeti postopek za izdelavo nove programske rešitve
Po drugi iteraciji ugotovimo, da je edina rešitev za povečanje funkcionalnosti izdelava nove programske rešitve, saj je obstoječa programska rešitev izdelana v neustrezni tehnologiji. V tretji iteraciji upoštevamo ugotovitve prve in druge iteracije, ki pomenijo povečanje stroškov, zato z odločitvenim diagramom preverimo tudi vidik visoke cene razvoja. Potek odločitve bi bil tak, kot je predstavljen na sliki 23. Zaradi visokih stroškov najprej preverimo, ali je možna zamenjava programske rešitve z alternativno rešitvijo. Ugotovili bi, da alternativne rešitve obstajajo, vendar nimajo vseh ustreznih funkcionalnosti, dodatno bi ugotovili, da se alternativnih rešitev ne da enostavno razširiti. Zato se razišče, ali bi lahko obstoječa rešitev pokrivala funkcionalnosti, ki jih nova ne podpira, preostale funkcionalnosti pa bi prevzela nova programska rešitev. Ker to ni možno, se preveri, ali se lahko težave s ceno reši s spremembo razvojne metodologije, a ker podjetje ni imelo ustreznih znanj o razvojnih metodologijah, je imelo na voljo tri možnosti: sodelovanje z zunanjim izvajalcem, izobraževanje ali pa dodatno zaposlovanje.
60
Slika 23: Odločitev glede nadaljnjega razvoja programske rešitve za življenjska zavarovanja zaradi cene razvoja
Po tretji iteraciji ponovno dobimo tri možnosti, in sicer, da se mora podjetje povezati z zunanjim izvajalcem, da mora vlagati v dodatno izobraževanje ali pa, da se dodatno zaposli kader, ki ima ustrezna znanja. Če vse skupaj strnemo, je odgovor le ta: potrebno je pričeti postopek za izdelavo nove programske rešitve in pridobiti ustrezna znanja, bodisi preko novih zaposlenih, preko izobraževanja ali pa s sodelovanjem z zunanjim izvajalcem. Diagram je pripeljal do enake odločitve, kot so jo sprejeli v podjetju. Odločitev se je tudi v praksi izkazala za pravilno.
61
9.3.2 Opustitev razvoja programske rešitve za spremljanje opravljenega dela V podjetju Marand so v letu 2002 pričeli uporabljati orodje JIRA. Orodje je namenjeno spremljanju projektov in beleženju ter planiranju zahtev projektov. Za potrebe spremljanja opravljenega dela, torej beleženje ur, JIRA v osnovi ni zagotavljala zadostne podpore, zato je podjetje leta 2004 izdelalo lastno razširitev, poimenovano Kukavica. Razširitev je še vedno v uporabi, žal pa ni volje in energije za posodobitve programske rešitve. Podjetje se ukvarja z vprašanjem, ali naj se razvoj programske rešitve nadaljuje ali naj se jo zamenja z drugo rešitvijo. Skozi odločitveni diagram se bom sprehodil, kot da smo v letu 2008, in tako, kot bi se odločili danes, torej leta 2016. Za leto 2008 je potek odločanja predstavljen na sliki 24.
Slika 24: Odločitev glede nadaljnjega razvoja programske rešitve za vodenje opravljenega dela podjetja Marand leta 2008
Programska rešitev ima težave z visokimi stroški razvoja
Stroške lahko znižamo z zamenjavo programske rešitve
Obstaja alternativna programska rešitev
Nova programska rešitev ne pokriva obvezne funkcionalnosti
Nove programske rešitve se ne da razširiti
Stara programska rešitev ne more pokriti dela funkcionalnosti
Zamenjava metodologije Odprta kodaTrženje lastne rešitve
Odločitveni diagram ponudi tri možnosti: zamenjavo metodologije, trženje lastne rešitve ali predajo programske rešitve v skupni razvoj, odprto kodo.
62
Leta 2008 se je podjetje Marand odločilo, da se razvoj nadaljuje, vendar v zelo omejenem obsegu. Če bi bila leta 2008 sprejeta strateška odločitev za trženje rešitve, bi prehiteli konkurenco in bi danes podjetje Marand tržilo produkt, podoben produktu Tempo, omenjenem v poglavju »Kriteriji predelave programske rešitve v produkt«. Za isto programsko rešitev se skozi odločitveni diagram sprehodimo še v letu 2016. Potek odločanja je predstavljen na sliki 25. Slika 25: Odločitev glede nadaljnjega razvoja programske rešitve za vodenje opravljenega
dela podjetja Marand leta 2016
Odločitveni diagram ponudi tri možnosti: zamenjavo lastne rešitve s kupljeno rešitvijo, trženje lastne rešitve ali predajo programske rešitve v skupni razvoj, odprto kodo. Dokončna odločitev o nadaljnjem razvoju programske rešitve še ni bila sprejeta, je pa velika verjetnost, da se bo razvoj opustilo in se bo programsko rešitev zamenjalo z alternativno programsko rešitvijo.
63
9.4 Prednosti uporabe diagrama poteka Predstavljeni odločitveni diagram na enostaven in pregleden način predstavi problematiko odločitve o opustitvi razvoja programske rešitve. Uporabnika usmeri, da se osredotoči na bistvena vprašanja, ki zadevajo nadaljnji razvoj programske rešitve. V množici možnih kriterijev, ki lahko vplivajo na odločitev o opustitvi razvoja, kot so bili našteti v poglavju o razvrstitvi kriterijev, težko odkrijemo bistvene kriterije. Prav tako predstavlja težavo to, da je pomembnost kriterijev za različne programske rešitve zelo različna. Diagram poteka se veliki količini kriterijev izogne in najprej zahteva splošni odgovor na to, kaj je glavna težava razvoja, na ta način pa lahko poenostavi odločitev. Ugotovitev, da se je potrebno najprej vprašati, kaj je glavni razlog za zamenjavo programske rešitve, se morda sliši samoumevna, vendar se v praksi običajno izkaže, da motivi za ukinitev pogosto nimajo kaj dosti povezave z delovanjem programske rešitve, temveč so v ozadju osebni interesi, ki niso v skladu z interesi podjetja. Diagram poteka v posameznih korakih zahteva jasne odgovore, zato bi morala biti odločitev o opustitvi razvoja programske rešitve na podlagi diagrama poteka bolj pregledna.
9.5 Slabosti uporabe diagrama poteka Slabosti diagrama izvirajo iz istega razloga kot prednosti. Da je diagram lahko pregleden in enostaven, ne sme vsebovati vseh kriterijev, ki lahko vplivajo na odločitev o opustitvi razvoja. Če bi se zanašali samo na diagram, bi lahko izpustili kak bistven kriterij, ki bi lahko vplival na odločitev o opustitvi razvoja programske rešitve.
9.6 Priložnosti za izboljšave diagrama poteka Diagram bi se dalo razširiti z dodatnimi kriteriji, predvsem v delu, kjer je trenutno navedena »strateška odločitev«. Zaradi preglednosti in enostavnosti diagrama tega nisem izvedel, je pa to vsekakor možnost izboljšave diagrama. Ko v diagramu pridemo do točke, da lastni razvoj ni bistveno cenejši, bi lahko dodal dodatno vprašanje, ali je podjetje pripravljeno tržiti programsko rešitev, če bi bil pozitiven odgovor rešitev trženje lastne rešitve, če bi bil odgovor negativen, pa bi bilo naslednje vprašanje, ali je podjetje pripravljeno predati rešitev v prosto kodo, če bi bil odgovor pozitiven, je rešitev prosta koda, če pa bi bil odgovor negativen, bi bila zadnja in edina opcija zamenjava lastne rešitve s kupljeno rešitvijo. Je pa vprašanje, ali ne bi s temi dodatnimi vprašanji prehitro preusmeril pozornosti in bi na ta način uporabnik diagrama spregledal katero izmed opcij. Podobno bi se dalo razširiti tudi zaključek »zamenjava/nadgraditev metodologije«, kjer bi se dalo ugotoviti, kaj je vzrok, da trenutna metodologija ne daje ustreznih rezultatov. Lahko bi se vprašali, kaj je trenutno glavna težava metodologije, in poiskali ustrezna orodja za reševanje konkretne težave, kot je prikazano na sliki 12.
64
Dodatno bi bilo potrebno raziskati, kako na odločitev o nadaljnjem razvoju vplivajo medsebojni odnosi znotraj razvojne ekipe in odnosi med razvojno ekipo in uporabniki ter vodstvom podjetja. Delno je to že pokrito znotraj metodologije dela. Diagram bi bilo potrebno dodatno testirati z več primeri odločitev o opustitvi razvoja. Ob dodatnih testiranjih bi se verjetno pojavili tudi drugi ključni kriteriji, ki trenutno še niso zajeti, in dodatno bi se potrdilo, ali so trenutna vprašanja in odgovori res ustrezni. Zanimiva bi bila analiza primerov dejanskih odločitev, kjer se je naknadno izkazalo, da odločitev o opustitvi ali nadaljevanju razvoja programske rešitve ni bila ustrezna, in predlogov, ki bi jih za isti primer ponudil odločitveni diagram.
SKLEP Odgovor na ključno raziskovalno vprašanje magistrskega dela – kateri so kriteriji, ki bistveno vplivajo na odločitev o nadaljnjem razvoju programske rešitve – sem iskal s pregledom relevantne literature in iskanjem primerov, ko se je podjetje odločalo, ali naj nadaljuje ali opusti razvoj programske rešitve. Ob iskanju literature me je presenetilo, da literature, ki bi se ukvarjala s podobnim vprašanjem, skoraj ni, kar je nenavadno, saj se vsako podjetje, ki ima lastni razvoj, slej ko prej sooči z vprašanjem o smiselnosti nadaljnjega razvoja programske rešitve, saj se razvoj vsake programske rešitve enkrat konča. Najprej sem raziskal kriterije, kot so uporabnost, zanesljivost, učinkovitost, stroški vzdrževanja, ustrezne funkcionalnosti. Vse kriterije sem opisal in naštel v eni tabeli, kar je lahko v procesu odločanja opustitve razvoja programske opreme v veliko pomoč, saj so na enem mestu zbrani vsi relevantni kriteriji. Med pregledom literature sem ugotovil, da ima na velik del kriterijev odločilen vpliv metodologija razvoja programske rešitve, zato sem raziskal, kaj je metodologija razvoja in kakšne metodologije razvoja poznamo ter kako vplivajo na razvoj programske rešitve. Na podlagi prebrane literature sem pripravil seznam kriterijev, s katerimi lahko ocenimo metodologijo razvoja, in opisal, kako lahko s posameznimi procesi metodologij vplivamo na razvoj programske rešitve. Glede na prebrano literaturo sklepam, da prva teza drži, neustrezna metodologija razvoja lahko onemogoča nadaljnji razvoj programske rešitve. Z enostavnim diagramom sem prikazal, katere tehnike se mora uvesti v metodologijo razvoja, da se odpravi posamezne tipe napak razvoja. Raziskal sem tudi, kako na opustitev razvoja vpliva vrsta in namen programske rešitve, vendar bistvenih vplivov nisem zaznal. Ob raziskovanju sem zaznal, da na odločitev vpliva predvsem dejstvo, ali se razvoj v celoti odvija znotraj podjetja ali pa delno pri zunanjih izvajalcih. Če je del razvoja pri zunanjih izvajalcih, je odločitev o opustitvi razvoja lahko
65
lažja, saj nimamo toliko težav z odvečnimi kadri, vendar tudi pri zunanjem razvoju odločitev ni tako enostavna, saj imamo lahko težave z odpovednimi roki in pogodbenimi kaznimi. Preveril sem, kakšne so možnosti nadaljnjega razvoja, če podjetje ugotovi, da so stroški razvoja previsoki. Poleg nižanja stroškov razvoja z optimizacijo metodologije razvoja sem našel še dve možnosti. Prva možnost je predelava programske rešitve v produkt in začetek trženja produkta. Tukaj sem našel odgovor na drugo tezo, da pojav komercialnih rešitev, ki pokrivajo funkcionalnosti, ki jih podjetje potrebuje, a pokriva z lastno programsko rešitvijo, še ne pomeni, da je nadaljnji razvoj lastne programske rešitve nesmiseln. Primer je podjetje Tempo, ki je pričelo s trženjem rešitve, prvotno namenjene lastni uporabi, in to navkljub dejstvu, da so na trgu že obstajale podobne rešitve. Poiskal sem kriterije, ki morajo biti izpolnjeni, da je predelava programske rešitve, prvotno namenjene interni uporabi, na tržni produkt smiselna. Druga možnost je predelava programske rešitve v odprtokodno rešitev, kjer sem našel primer Eclipse, kjer so podjetja ocenila, da bodo s skupnim razvojem dosegla več, kot če nadaljujejo s samostojnim razvojem. Glede na izkušnje in pregledano literaturo podjetja pogosto zanemarijo možnost, da lahko lastno rešitev predelajo v produkt ali pa jo predajo v odprto kodo. Med pregledom literature sem izluščil tri ključne kriterije za opustitev programske rešitve, to so kvaliteta, funkcionalnosti in cena. Vse kriterije za opustitev razvoja, na katere sem med raziskovanjem naletel, lahko razvrstimo v enega ali vse tri ključne kriterije. Pripravil sem seznam vseh kriterijev in določil, pod katerega izmed treh ključnih kriterijev spadajo. Trije ključni kriteriji se izkažejo kot pomembni, ker zahtevajo jasen odgovor o tem, kaj je glavni razlog za opustitev razvoja. Eden izmed ciljev naloge je bil izdelava odločitvenega diagrama, ki bi na enostaven način podal odgovor, ali je nadaljnji razvoj programske rešitve še smiseln. Začetno vprašanje izdelanega diagrama je, kateri izmed treh ključnih kriterijev ima največjo težo za opustitev razvoja programske rešitve, nato pa na podlagi nadaljnjih vprašanj in odgovorov pridemo do odgovora, kaj je potrebno narediti s programsko rešitvijo, da je njen nadaljnji razvoj še smiseln. V diagram nisem vključil vseh najdenih kriterijev, saj bi bil tak diagram prevelik in nepregleden, vključil sem tisto, kar se je ob pregledu primerov izkazalo kot najbolj pomembno. Izdelani diagram sem preizkusil na dveh primerih, kjer se je dejansko odločalo o opustitvi programske rešitve, in diagram je dal smiselne odgovore. Diagram se kaže kot dobra osnova za nadaljnje raziskovanje, bi ga pa bilo potrebno testirati z več realnimi primeri. S tem sem delno potrdil tezo, da se kriterije lahko razvrsti v pregleden diagram poteka, delno zato, ker v diagram nisem mogel vključiti vseh kriterijev, saj bi z vključitvijo vseh kriterijev diagram postal nepregleden in neuporaben. Je pa predstavljeni diagram uporaben in lahko poda ustrezen odgovor na vprašanje o opustitvi lastnega razvoja. Predvsem je pomembno to, da na vsakem koraku zahteva jasne odgovore za prehod na naslednjo stopnjo, kar lahko pripomore k preglednosti in utemeljitvi končne odločitve o nadaljnjem razvoju programske rešitve.
66
LITERATURA IN VIRI 1. April, A., Abran, A. (2008). Software Maintenance Management: Evaluation and
Continuous Improvement. New Jersy: John Wiley & Sons. 2. Baškovec, D. (2013). Agilne metode managmenta projektov s poudarkom na metodi
Scrum na primeru razvoja GPS storitve (diplomsko delo). Ljubljana: Ekonomska fakulteta.
3. Beck, K. (2000). Extreme Programming Explained: Embrace Change. Boston: Addison–Wesley.
4. Bengtsson, P., Lassing, N., Bosch, J., Vliet, H. (2000). Analyzing Software Architectures for Modifiability. Najdeno 24. marca 2016 na spletnem naslovu http://www.diva–portal.org/smash/record.jsf?pid=diva2%3A838104&dswid=–8239
5. Bennatan, E. M. (2006). Catastrophe Disentanglement: Getting Software Projects Back on Track (1st ed.). Boston: Addison–Wesley.
6. Berdugo, M. (2014). Software Development – In House vs Outsourcing. V Linkedin. Najdeno 1. februarja 2016 na spletnem naslovu https://www.linkedin.com/pulse/20140724152738–2996742–software–development–in–house–vs–outsourcing
7. Bergmayer, A. (2013). Migrating Legacy Software to the Cloud with ARTIST.
Software Maintenance and Reengineering (CSMR), 2013 17th European Conference. 465–468.
8. Bitner, M. (2012). Organizational Approaches to Managing Tacit Knowledge Loss of Legacy System Information Technology Professionals. Najdeno 24. marca 2016 na spletnem naslovu http://search.proquest.com/docview/1114900385
9. Bloch, M., Blumberg, S., Laartz, J. (2011). Delivering large–scale IT projects on time, on budget, and on value. Najdeno 29. marca 2016 na spletnem naslovu http://www.mckinsey.com/business-functions/business-technology/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
10. Bonnie, E. (2015). Complete Collection of Project Management Statistics 2015. Najdeno 24. marca 2016 na spletnem naslovu https://www.wrike.com/blog/complete–collection–project–management–statistics–2015/#failure
11. Braude, E. J., Bernstein, M. E. (2016) Software Engineering: Modern Approaches (2nd ed.). Illinois: Waveland Press.
12. Capers, J., Bonsignour, O. (2011). The Economics of Software Quality. Massachusetts: Addison–Wesley.
13. Chrillo, J., Danielyan, E. (2005). Sun Certified Security Administrator for Solaris 9 & 10 Study Guide. Emeryville: McGraw–Hill.
14. Comparing workflows. (b. l.). Najdeno 21. junija 2016 na spletnem naslovu https://www.atlassian.com/git/tutorials/comparing–workflows
67
15. Cooper, S. (2015). The Pros and Cons of Off–the–shelf Software. Najdeno 19. maja 2016 na spletnem naslovu http://www.hero–solutions.co.uk/articles/bespokevsofftheshelf.asp
16. Clydebuilt Business Solutions Ltd. (2012). Developing In–House Vs. Off the Shelf (white paper). Najdeno 15. februarja 2016 na spletnem naslovu http://www.clydebuiltsolutions.com/wp–content/uploads/2012/05/Inhouse–VS–Off–the–Shelf–May.pdf
17. Dectar. (b. l.). About Dectar. Najdeno 25. junija 2016 na spletnem naslovu http://www.dectar.com/about–dectar
18. Eclipse. (b. l.). About Eclipse. Najdeno 25. junija 2016 na spletnem naslovu https://eclipse.org/org/
19. Emam, K. E., Koru, A. G. (2008). A Replicated Survey of IT Software Project Failures. IEEE Software 25(5), 84–90.
20. Fenton, N., Bieman, J. (2015). Software Metrics: A Rigorous and Practical Approach (3rd ed.). Florida: CRC Press.
21. Fink, L. (2014). Why project size matters for contract choise in software development outsorcing. ACM SIGMIS 4(3), 54–71.
22. Florentine, S. (2014). CIOs Should Prepare for Lack of Cobol (Yes, Cobol) Developers. CIO. Najdeno 24. marca 2016 na spletnem naslovu http://www.cio.com/article/2690555/careers–staffing/cios–should–prepare–for–lack–of–cobol–yes–cobol–developers.html
23. Flowchart Symbols. Najdeno 21. junija 2016 na spletnem naslovu https://www.smartdraw.com/flowchart/flowchart-symbols.htm
24. Flyvbjerg, B., Budzier, A. (2011). Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, 89(9), 601–603.
25. Gandham, M. (2014). How can I transform an internal software system in my company into a full–fledged product for the market? Najdeno 26. junija 2016 na spletnem naslovu https://www.quora.com/How–can–I–transform–an–internal–software–system–in–my–company–into–a–full–fledged–product–for–the–market.
26. Gardner, D. (2006). Not just a nip and tuck, application modernization extends the lifecycle of legacy code assets. Najdeno 25. marca 2016 na spletnem naslovu http://www.zdnet.com/article/not–just–a–nip–and–tuck–application–modernization–extends–the–lifecycle–of–legacy–code–assets/
27. Git Basics. (b. l.). Najdeno 21. junija 2016 na spletnem naslovu https://git–scm.com/book/en/v2/Getting–Started–Git–Basics
28. Groenfeldt, T. (2013). Outdated Enterprise Accounting Platforms Are A Hazard. Forbes. Najdeno 24. marca 2016 na spletnem naslovu http://www.forbes.com/sites/tomgroenfeldt/2013/01/16/outdated–enterprise–accounting–platforms–are–a–hazard–woodbine/#64cb6bc01821
29. Grom, J. (2009). Arhitektura integracije podedovanih aplikacij (diplomsko delo). Ljubljana: Fakulteta za računalništvo in informatiko.
68
30. Groznik, S. (2009). Model skladiščnega poslovanja in outsorcing skladišč v logističnem podjetju (magistrsko delo). Maribor: Fakulteta za logistiko.
31. Heeks, R. (2001). Synching or sinking: global software outsourcing relationships. IEEE Software. 18(2), 54–60.
32. Hauer, D. (2013). Analiza primernosti razvojne metodologije informacijskih sistemov Scrum za izbrano razvojno ekipo (magistrsko delo). Ljubljana: Ekonomska fakulteta.
33. Hayes, J. (2014). The Theory and Practice of Change Management (4th ed.). New York: Palgrave Macmillan.
34. Higsmith, J. A. (2002). Agile Software Development Ecosystems. Boston: Addison–Wesley.
35. Highsmith J. A. (2013). Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York: Dorset House Publishing.
36. Jackson, M., Crouch, S., Baxter, R. (2011). Software Evaluation: Criteria–based Assessment. Najdeno 24. marca 2016 na spletnem naslovu http://software.ac.uk/sites/default/files/SSI–SoftwareEvaluationCriteria.pdf
37. Kašnik, M. (2014). Uporaba agilnih metod pri razvoju programske opreme v slovenskih start–up podjetjih (diplomsko delo). Ljubljana: Fakulteta za računalništvo in informatiko.
38. Kendrick, T. (2015). Identifying and managing project risk (3rd edition). New York: AMACOM.
39. Korber, R. (2002). Zunanje izvajanje dejavnosti. INFO SRC.SI, Ljubljana, 34(2002), str. 3–6.
40. Koskinen, J., Ahonen, J. J., Sivula, H., Tilus, T., Lintinen, H., Kankaanpaa, I. (2005).
Software Modernization Decision Criteria: An Empirical Study, Software Maintenance and Reengineering, 2005. CSMR 2005. Ninth European Conference on Software Maintenance and Reengineering (str. 324 – 331). Manchester: UK.
41. Kringsman, M. (2009). Study: 68 percent of IT projects fail. Najdeno 24. marca 2016 na spletnem naslovu http://www.zdnet.com/article/study–68–percent–of–it–projects–fail/
42. Manifesto for Agile Software Development. (b. l.). Najdeno 24. aprila 2016 na spletnem naslovu http://agilemanifesto.org/
43. Martin, R. C. (2003). Agile Software Development: Principles, Patterns, and Practices. New York: Prentice Hall.
44. Medical services flowchart. Najdeno 21. junija 2016 na spletnem naslovu https://www.smartdraw.com/flowchart/examples/medical–services–flowchart/
45. Myers, G. J., Sandler, C., Badgett, T. (2012). The Art of Software Testing (3rd ed.). New Jersy: John Willey & Sons.
46. Morgan, L. (2013). Killing Your Company’s Legacy Applications – the Right Way. Najdeno 6. maja 2016 na spletnem naslovu https://www.mendix.com/think–tank/killing–your–companys–legacy–applications–the–right–way/
69
47. Muilwijk, R. (2016). Top 11 project management tools for 2016. Najdeno 21. junija 2016 na spletnem naslovu https://opensource.com/business/16/3/top–project–management–tools–2016
48. Ograjenšek, A. (2013). Uporaba metode Kanban pri razvoju programske opreme (diplomsko delo). Ljubljana: Fakulteta za računalništvo in informatiko.
49. Open Source Initiative. (2016). Najdeno 6. maja 2016 na spletnem naslovu https://opensource.org/about
50. Patterson, D. A. & Hennessy, J. L. (2013). Computer Organization and Design (5th ed.). Waltham: Elsevier Inc.
51. Penev, M. (2006). Večkriterijski odločitveni model za izbiro celovite programske rešitve (magistrsko delo). Ljubljana: Ekonomska fakulteta.
52. Pérez R. C., de Guzman, I. G. R., Piattini, M. (2014). Diagnosis of software erosion through fuzzy logic. Najdeno 24. marca 2016 na spletnem naslovu https://www.researchgate.net/publication/252016835_Diagnosis_of_software_erosion_through_fuzzy_logic
53. Planinc, S. (b. l.). Ocena kakovosti programske opreme za prenočitvene obrate. Najdeno 1. junija 2016 na spletnem naslovu http://www2.arnes.si/~sudsplan/oph/IzbiraPms.pdf
54. Prednosti agilnega razvoja. (b. l.). Najdeno 24. marca 2016 na spletnem naslovu https://www.versionone.com/agile–101/agile–software–development–benefits/
55. Reifer, D. J. (2006). Software Management (7th edition). New Jersy: John Willey & Sons.
56. Royce, W. (1970) Managing the development of large software systems. Najdeno 1. julija 2016 na spletnem naslovu https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
57. Rojko, M. (2011). Uporaba agilne metodologije »SCRUM« pri razvoju državnega portala za poslovne subjekte (magistrsko delo). Ljubljana: Ekonomska fakulteta.
58. Rusk J. (2012). In–house development vs Outsourcing. V AgileKiwi. Najdeno 15. februarja 2016 na spletnem naslovu http://agilekiwi.com/estimationandpricing/in–house–development–vs–outsourcing
59. Sahay, S., Nicholson, B., Krishna, S. (2003). Global IT Outsourcing: Software Development across Borders. Cambridge: Cambridge University Press.
60. Sauro, J. (2011). 10 Essential Usability Metrics. Najdeno 21. julija 2016 na spletnem naslovu http://www.measuringu.com/blog/essential–metrics.php
61. Savolainena, P., Ahonena, J. J., Richardson, I. (2012). Software development project success and failure from the supplier's perspective: A systematic literature review. International Journal of Project Management 30(4), 458–469.
62. Schulmeyer, G. G., Mackenzie, G. R. (2000). Verification and Validation of Modern Software–Intensive Systems (1st Edition). New York: Prentice Hall.
63. Schwalbe, K. (2015). Information Technology Project Managment (8th ed.). Boston: Cengage Learning.
70
64. Security testing (b. l.). Najdeno 21. junija 2016 na spletnem naslovu naslovu https://en.wikipedia.org/wiki/Security_testing
65. Singh, H., Pal, P. (2013). Software Reliability Testing using Monte Carlo Methods.
International Journal of Computer Applications 69(4), 41–44 66. Srinivas, M., Ramakrishna, G., Rajasekhara, R. K., Suresh, B. E. (2016). Analysis of
Legacy System in Software Application Development: A Comparative Survey. International Journal of Electrical and Computer Engineering (IJECE), 6(1).
67. Software reliability testing. (b. l.). Najdeno 21. junija 2016 na spletnem naslovu naslovu https://en.wikipedia.org/wiki/Software_reliability_testing
68. Tempo. (b. l.). Najdeno 26. junija 2016 na spletnem naslovu http://tempo.io/press/. 69. The types of software broken down. (2012). Najdeno 6. junija 2014 na spletnem naslovu
https://davinashahict.wordpress.com/2012/09/28/the–types–of–software–broken–down/
70. Tompkins, J. (2016). Top 40 Risks in Outsourcing. Najdeno 11. maja 2016 na spletnem naslovu http://www.tompkinsinc.com/top–40–risks–outsourcing/
71. Vodopivec, S. (2008). Zunanje izvajanje informatike kot vzvod zagotavljanja konkurenčne prednosti (magistrsko delo), Ljubljana: Ekonomska fakulteta.
72. Warren, I. (1999). The Reinaissance of Legacy systems. Nottingham: Springer. 73. Wiegers, K. (2013). Creating a Software Engineering Culture. New York: Addison–
Wesley. 74. Wiegers, K., Beatty J. (2013). Software Requirements (3rd ed.). b.k.: Pearson Education. 75. Williams, A. (2001). Apllication Management Outsourcing versus Insourcing. Najdeno
29. maja 2016 na spletnem naslovu http://www.keystoneisit.com/outsource.pdf 76. Wua, F., Lia, H.Z., Chub, L.K., Scullib, D. (2012). Supplier selection for outsourcing
from the perspective of protecting crucial product knowledge. International Journal of Production Research 51(5)
77. Značilnosti in prednosti agilnega razvoja. (b. l.). Najdeno 24. aprila 2016 na spletnem naslovu http://www.design–management.si/znacilnosti–in–prednosti–agilnega–razvoja/
1
PRILOGA 1: Slovarček slovenskih prevodov tujih izrazov Bespoke software – programska rešitev, izdelana na zahtevo naročnika Code review – pregledovanje kode Completion Rates Metric – ocena izvedljivosti naloge Conversion Metric – merjenje uspešno izvedenih transakcij Custom software – programska rešitev, izdelana na zahtevo naročnika Errors Metric – napake uporabe Expectation Metric – pričakovanje Flowchart – diagram poteka Functional Testing – funkcionalno testiranje Freeware software – brezplačno programje In-house software – programska rešitev, izdelana z lastnimi viri za lastne potrebe Insourcing – najem zunanjih izvajalcev za delo pri naročniku Just In Time – koncept proizvodnje ali nabave ob pravem času Manifesto for Agile Software Development – manifest agilnega programskega razvoja Off the shelf software – serijsko programje Open source software – odprta koda Outsourcing – zunanje izvajanje Page Views/Clicks Metrics – število klikov Proprietary software – lastniška programska oprema Single Usability Metric (SUM) – skupna ocena uporabnosti Tailor-made software – programska rešitev, izdelana po meri na zahtevo naročnika Task Level Satisfaction Metric – stopnja zadovoljstva ob izvedbi naloge Task Time Metric – čas za izvedbo naloge Test Level Satisfaction Metric – stopnja zadovoljstva testiranja uporabnosti Usability Problems Metric – težave z uporabniškim vmesnikom