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/

PRILOGA

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