Univerza v Ljubljani
Fakulteta za raˇ cunalniˇ stvo in informatiko
Nace Seliˇsnik
Vpliv kljuˇ cnih praks DevOps na kakovost programske opreme
DIPLOMSKO DELO
VISOKOˇSOLSKI STROKOVNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : izr. prof. dr. Damjan Vavpotiˇ c
Ljubljana, 2021
koriˇsˇcenje rezultatov diplomske naloge je potrebno pisno privoljenje avtorja, Fakultete za raˇcunalniˇstvo in informatiko ter mentorja.
Fakulteta za raˇcunalniˇstvo in informatiko izdaja naslednjo nalogo:
Vpliv kljuˇcnih praks DevOps na kakovost programske opreme.
Tematika naloge:
V okviru diplomskega dela najprej preuˇcite pristop DevOps in ga kratko primerjajte z uveljavljenimi agilnimi pristopi za razvoj programske opreme.
Nato na podlagi pregleda relevantne literature identificirajte kljuˇcne prakse pristopa DevOps in njihov vpliv na faktorje kakovosti programske opreme po modelu ISO/IEC 25010. V drugem delu naloge pripravite in izvedite anketo med razvijalci v slovenskih malih in srednjih podjetjih, ki programsko opremo razvijajo po pristopu DevOps, z namenom, da izmerite njihove percepcije glede vpliva praks DevOps na kakovost. Rezultate predstavite in kritiˇcno ovrednotite.
Zahvaljujem se mentorju za pomoˇc pri diplomski nalogi in starˇsema, ki sta mi omogoˇcila ˇstudij.
Kazalo
Povzetek Abstract
1 Uvod 1
1.1 Motiv in cilji . . . 2 1.2 Struktura dela . . . 2
2 Agilni razvoj programske opreme 5
2.1 Manifest agilnosti . . . 5 2.2 Agilni pristopi . . . 7 2.3 Primerjava med agilnimi pristopi in pristopom DevOps . . . . 13 3 Model kakovosti programske opreme ISO/IEC 25010 15 3.1 Faktorji kakovosti v modelu ISO/IEC 25010 . . . 16 4 Kljuˇcne prakse DevOps in njihov vpliv na faktorje kakovosti
po modelu ISO/IEC 25010 21
4.1 Aktivno sodelovanje strani udeleˇzenih v razvoju programske opreme (angl. Active Stakeholder Participation) . . . 22 4.2 Avtomatizirano testiranje (angl. Automated Testing) . . . 23 4.3 Integrirano upravljanje konfiguracije (angl. Integrated Confi-
guration Management) . . . 25 4.4 Integrirano upravljanje sprememb (angl. Integrated Change
Management) . . . 25
4.7 Spremljanje (angl. Monitoring) . . . 27 5 Vpliv praks DevOps na kakovost po modelu ISO/IEC 25010
v slovenskih MSP 29
5.1 Primerjava vpliva praks DevOps na faktorje kakovosti med cenejˇsimi in draˇzjimi projekti . . . 34 5.2 Primerjava vpliva praks DevOps na faktorje kakovosti glede
na ˇcas trajanja projekta . . . 36 5.3 Primerjava vpliva praks DevOps na faktorje kakovosti glede
na ˇstevilo ˇclanov v projektni ekipi . . . 40
6 Zakljuˇcek 43
Literatura 46
Seznam uporabljenih kratic
kratica angleˇsko slovensko
XP Extreme programming Ekstremno programiranje QA Quality assurance Zagotavljanje kakovosti ISO International Organization for
Standardization
Mednarodna organizacija za standardizacijo
IEC International Electrotechnical Commission
Mednarodna komisija za elek- trotehniko
M Mean Povpreˇcje
MSP Small and medium-sized enter- prises
Mala in srednje velika podjetja
Povzetek
Naslov: Vpliv kljuˇcnih praks DevOps na kakovost programske opreme Avtor: Nace Seliˇsnik
V delu je opisan agilni razvoj programske opreme, njegove znaˇcilnosti in naˇcela. Predstavljena sta dva najbolj prepoznavna agilna pristopa, to sta XP in Scrum, dodatno pa je opisan tudi pristop DevOps. Poleg znaˇcilnosti teh treh pristopov diplomsko delo opisuje razlike med agilnimi pristopi in De- vOps. Kakovost je ena bistvenih lastnosti programske opreme, zato je v delu predstavljen model kakovosti ISO/IEC 25010, ki vkljuˇcuje vse potrebne fak- torje za kakovostno programsko opremo. V nadaljevanju se naloga dotakne bistvenih praks DevOps, ki se uporabljajo za zagotavljanje kakovosti v pro- gramski opremi, najbolj pa smo pozorni, na kateri faktor kakovosti po modelu ISO/IEC 25010 vpliva doloˇcena praksa. Na koncu so predstavljeni rezultati ankete, kjer smo razvijalce v malih in srednje velikih podjetjih spraˇsevali, kaj si mislijo glede praks DevOps in njihovega vpliva na faktorje kakovo- sti. S pomoˇcjo Mann-Whitneyevega U testa smo primerjali projekte glede na njihovo vrednost, ˇcas trajanja in ˇstevilo razvijalcev, ki so bili prisotni v projektu.
Kljuˇcne besede: agilni pristopi, DevOps, prakse DevOps, faktorji kakovo- sti, ISO/IEC 25010.
Abstract
Title: The impact of key DevOps practices on software quality Author: Nace Seliˇsnik
The thesis describes the agile development of software, its characteristics and principles. The two most recognizable agile agile methodologies, XP and Scrum, are presented, and the DevOps methodology, which complements the agile methodology, is additionally described. In addition to the characteris- tics of these three models, the thesis describes the differences between agile methods and DevOps. Quality is one of the essential features of software, so the part presents the ISO / IEC 25010 quality model, which includes all the necessary factors for quality software. In the following, the task touches on the essential DevOps techniques used to ensure quality in software, and we pay the most attention to which quality factor according to the ISO / IEC 25010 model is influenced by a particular technique. Finally, we present the results of a survey asking developers in SMEs what they think about DevOps practices and their impact on quality factors. The Mann-Whitney U test was used to compare the projects in terms of their value, duration and the number of developers present in the project.
Keywords: agile methodologies, DevOps, DevOps practices, quality factors, ISO/IEC 25010.
Poglavje 1 Uvod
V ˇcasu, ko se svet vse bolj avtomatizira, digitalizira, ter raˇcunalniki na- domeˇsˇcajo naˇse miselne procese, postaja razvoj programske opreme vse po- membnejˇsi. Raˇcunalniˇstvo in naˇcin razvoja programov se vsakodnevno spre- minjata in napredujeta, zato je razvoj programov zahtevna naloga. Vsak naroˇcnik od podjetja oz. razvojne ekipe zahteva drugaˇcne funkcionalnosti, kar pomeni, da je vsaka programska reˇsitev individualna in unikatna. Plani- ranje projekta kot celote pred samim zaˇcetkom razvijanja programske opreme je zaradi raznolikosti nesmiselno, saj bo med projektom zagotovo priˇslo do veliko sprememb.
Naroˇcniki med izdelavo programske opreme spreminjajo uporabniˇske zah- teve, kar od razvijalcev zahteva veliko fleksibilnosti, hitrost razvoja program- ske opreme pa postaja ena glavnih prednosti razvojne organizacije. Do ne- davnega so razvojne ekipe uporabljale tradicionalne pristope, kjer je celoten sklop uporabniˇskih zahtev bilo potrebno podati v zaˇcetni fazi. Ker je takˇsen razvoj primeren le za projekte, kjer ne prihaja do sprememb, so se izkuˇseni inˇzenirji programske opreme leta 2001 odloˇcili, da bodo ustvarili nov naˇcin razvoja programske opreme. Pojavili so se namreˇc agilni pristopi, ki razvijal- cem oz. razvojnim ekipam omogoˇcajo, da se laˇzje odzivajo na spremembe in v krajˇsem ˇcasu pripravijo boljˇsi izdelek za naroˇcnika. Leta 2009 se je pojavil pristop DevOps, ki je nadgradnja agilnih pristopov.
1
Ko podjetje, ki izdeluje programske reˇsitve, preda ˇzeleno programsko opremo konˇcnemu kupcu, je pomembno, da je ta preizkuˇsena in kakovostna.
Poleg kakovosti je za podjetje pomembno, da programska oprema ustreza priˇcakovanjem, potrebam in zahtevam stranke. To lahko zagotovimo pred- vsem s stalno komunikacijo med razvojno ekipo in konˇcnimi uporabniki ter podrobnim poznavanjem procesa, ki ga razvijamo. Kakovost lahko razde- limo na kakovost procesa razvoja programske opreme in kakovost izdelka, v diplomskem delu pa se bomo osredotoˇcili na kakovost procesa razvoja, ki poslediˇcno pomeni tudi kakovostno programsko opremo.
S pomoˇcjo analize literature in izvedene ankete smo ugotavljali, na kateri faktor kakovosti po modelu ISO/IEC 25010 vpliva doloˇcena praksa DevOps.
Kljuˇcne prakse za zagotavljanje kakovosti v razvojnih procesih omogoˇcajo vsem podjetjem in razvojnim ekipam razvijanje boljˇsih in kakovostnejˇsih pro- gramov ter zagotavljajo prednost pred konkurenco.
1.1 Motiv in cilji
Vpliv praks DevOps na kakovost programske opreme je trenutno slabo razi- skano podroˇcje [31]. V okviru diplomske naloge smo si zato kot cilj zastavili preuˇciti vpliv pristopa DevOps na kakovost programske opreme. Da bi dose- gli ta cilj, smo identificirali kljuˇcne prakse DevOps za zagotavljanje kakovosti programske opreme, preuˇcili obstojeˇce raziskave glede vpliva teh praks na ka- kovost in izvedli lastno raziskavo, kjer smo ugotavljali vpliv praks DevOps na faktorje kakovosti programske opreme po standardu ISO/IEC 25010.
1.2 Struktura dela
Nalogo bomo zaˇceli z agilnimi pristopi, kjer bomo najprej opisali njihov na- stanek, nato pa bomo omenili dva poznana agilna pristopa in pristop DevOps, ki je nadgradnja agilnih pristopov. V tretjem poglavju bomo zajeli model kakovosti ISO/IEC 25010 in opisali pripadajoˇce faktorje kakovosti. ˇCetrto
Diplomska naloga 3 poglavje je namenjeno analizi kljuˇcnih praks DevOps in raziskovanju vpliva doloˇcene prakse DevOps na razliˇcne faktorje kakovosti. Peto poglavje vse- buje analizo ankete o vplivu praks DevOps na faktorje kakovosti programske opreme v slovenskih malih in srednje velikih podjetjih, ˇsesto poglavje pa je namenjeno zakljuˇcku diplomskega dela.
Poglavje 2
Agilni razvoj programske opreme
V tem poglavju se bomo najprej spoznali z besedo agilnost. Predstavljen bo zaˇcetek agilnega pristopa in dvanajst naˇcel agilnega razvoja program- ske opreme, nato bosta opisana dva agilna pristopa in pristop DevOps kot nadgradnja agilnih pristopov. Poglavje bomo zakljuˇcili s primerjavo med DevOps in agilnimi pristopi.
Zametki iterativnih in inkrementalnih pristopov izhajajo ˇze iz ˇsestdesetih let prejˇsnjega stoletja. Ljudje, ki so kritizirali tradicionalne pristope, so v devetdesetih letih predlagali alternativne pristope, ki so bili pravzaprav agilne ideje. Tako so se kot odgovor na tradicionalne pristope razvili lahki pristopi razvoja programske opreme, ki se sedaj imenujejo agilni pristopi [6].
2.1 Manifest agilnosti
Februarja 2001 se je v zvezni drˇzavi Utah zbralo 17 ljudi, ki so razpravljali o lahkih pristopih za razvoj programske opreme. Odloˇcili so se, da bodo pristope za razvoj programske opreme poimenovali agilni pristopi, nastal pa je tudi manifest. V njem je bilo zapisano: ”Odkrivamo boljˇse naˇcine za razvoj programske opreme tako, da jo naredimo in s tem pomagamo drugim.
5
Vrednote agilnega razvoja:
• Posamezniki in interakcije nad procesi in orodji.
• Delujoˇca programska oprema nad obseˇzno dokumentacijo.
• Sodelovanje s stranko pred pogodbenimi pogajanji.
• Odziv na spremembe pred sledenjem naˇcrta [21].”
Pri agilnih pristopih obseˇzna dokumentacija ni nujno slaba, glavni poudarek pa mora ˇse vedno nositi konˇcni izdelek. Razvojna ekipa mora sama ugo- toviti, katera vrsta dokumentacije je resniˇcno pomembna. Priporoˇceno je, da je stranka v stalnem sodelovanju z razvojno ekipo, saj tako ekipa laˇzje razume in dosega ˇzelje stranke. V spreminjajoˇcem okolju je sledenje naˇcrtu lahko tvegano, saj je naˇcrt zaslepil ˇze veliko razvijalcev, ki se zaradi njega niso odzvali na spremembe [21].
12 naˇcel agilnega razvoja programske opreme:
1. Zadovoljiti kupca z nenehno in zgodnjo dostavo programske opreme.
2. Spremembe so dobrodoˇsle tudi pozno v razvojnem procesu.
3. Delujoˇco programsko opremo je potrebno pogosto poˇsiljati stranki, na nekaj tednov do nekaj mesecev.
4. Sodelovanje med stranko in razvojno ekipo je potrebno skozi celoten projekt.
5. Projekte je potrebno graditi okoli motiviranih posameznikov.
6. Neposredni pogovor je najuˇcinkovitejˇsi naˇcin prenosa informacij.
7. Glavno merilo napredka na projektu je delujoˇca programska oprema.
8. Agilen naˇcin razvoja spodbuja trajen razvoj.
Diplomska naloga 7 9. Dobro oblikovanje in tehniˇcna podrobnost poveˇcujeta agilnost.
10. Preprostost je bistvenega pomena.
11. Ekipe, ki se organizirajo, same izdelujejo najboljˇse izdelke.
12. Ekipa mora v ˇcasovnih intervalih razmiˇsljati, kako bo postala bolj uˇcinkovita in se temu tudi prilagajati [5].
Nekateri udeleˇzenci sestanka so ustanovili organizacijo The Agile Alliance za promocijo agilnega razvoja [7]. Med razvijanjem nove metodologije so imeli v mislih predvsem dejstvo, da stranke spreminjajo zahteve in da mora biti sam proces razvoja fleksibilen. Njihov cilj je bil, da se razvojne ekipe hitreje odzovejo na spremembe, ki se lahko pojavijo med samim projektom. Razvilo se je torej veliko agilnih pristopov, ki pa imajo podobne temeljne vrednote [23, 9].
2.2 Agilni pristopi
Ko se ekipe zaˇcnejo oblikovati, si izbirajo pristope, po katerih se bodo orga- nizirali in delali. Po izbiri pristopa si ekipe doloˇcijo vloge, naˇcrtujejo urnike dela in izdaj ter organizirajo sodelovanje s stranko. Nastalo je veˇc agilnih pristopov za organizacijo dela oz. projekta, Slika 2.1 pa prikazuje odsto- tek uporabe le-teh, ki jih agilne ekipe uporabljajo po vsem svetu za boljˇse obvladovanje projektov [47].
Slika 2.1: Odstotek uporabe doloˇcenih agilnih pristopov (prirejeno po [3]).
2.2.1 Ekstremno programiranje XP
XP omogoˇca hitrejˇso odzivnost na nove zahteve, kakovostnejˇso program- sko opremo in uvedbo kontrolnih toˇck. Poudarja skupinsko delo in se za- vzema za pet vrednot, ki izboljˇsajo projekt. To so: komunikacija, prepro- stost, povratna informacija, pogum in spoˇstovanje [53]. Slika 2.2 prikazuje naˇcrtovanje programske opreme in povratne informacije v ekstremnem pro- gramiranju. Naˇcrtovanje v XP-ju se deli na identifikacijo zgodb, zaˇcetno oceno, naˇcrtovanje izdaj, naˇcrtovanje iteracij in naˇcrtovanje nalog. Najprej kupec namesto dolgega dokumenta napiˇse uporabniˇske zgodbe, ki pa ne smejo biti preveˇc tehniˇcne. Ekipa mora doloˇciti potreben ˇcas za izvajanje teh na-
Diplomska naloga 9 log. Nato se zgodbe pregledajo in razdelijo na manjˇse dele. Vsaka zgodba se toˇckuje, toˇckovanje pa predstavlja potreben napor za implementacijo [54].
Pri naˇcrtovanju izdaje se izberejo in izboljˇsajo zgodbe, ki bodo implementi- rane, doloˇci pa se tudi datum izdaje, ki je po navadi ˇcez nekaj mesecev. Vsaki izbrani zgodbi se doloˇcijo prioritete kot so: obvezno, potrebno, moˇzno, tokrat izpuˇsˇceno. V naˇcrtovanju iteracij naroˇcnik predstavi ˇzelene funkcionalnosti naslednje iteracije. Na podlagi predhodne iteracije se razvojna ekipa odloˇci, kaj bo storila v naslednji iteraciji. Iteracije po navadi trajajo dva tedna, za- kljuˇcijo pa se na datum izroˇcitve iteracije oz. programske opreme. Razvojna skupina po koncu iteracije pregleda implementirane zgodbe, za laˇzje predvi- devanje naslednjih iteracij pa se izraˇcuna tudi hitrost skupine [28]. Za tem se ponovno naˇcrtujejo naloge, ki bodo izvedene v naslednji iteraciji [53].
Tehnike, znaˇcilne za XP, so programiranje v paru, testno voden razvoj, zvezna integracija, povratne informacije strank v podjetju oz. pri razvijalcih, refaktoriranje kode, uporabniˇske zgodbe, sistemska metafora, arhitekturna konica, hitri sestanki, testiranje enot, sprejemno testiranje.
Slika 2.2: Naˇcrtovanje in povratne informacije v XP-ju (prirejeno po [20]).
2.2.2 Scrum
Za razliko od XP-ja, ki se usmerja v razvoj programske opreme, Scrum za- nima predvsem vodenje kompleksnih projektov. Je eden izmed najbolj pri- ljubljenih agilnih pristopov, ki se je uporabljal ˇse preden je nastal Manifest agilnega razvoja [2].
Skupino Scrum sestavljajo lastnik izdelka, razvojna skupina, skrbnik me- todologije in opazovalci [4]. Lastnik izdelka je zadolˇzen za projekt, pred- stavlja ˇclane in rezultate projekta. Zagotavlja sredstva projekta in vzdrˇzuje seznam zahtev (doloˇci prioriteto zahtev, oceni razvojni ˇcas). Razvojno ekipo sestavljajo razvijalci, preizkuˇsevalci in arhitekti, ki so zadolˇzeni za razvoj reˇsitev, izbiro tehnik in naˇcina za realizacijo izdelka. Skrbnik metodologije skrbi, da se upoˇstevajo pravila metodologije Scrum in pomaga pri blokadah oz. teˇzavah. Nadzira ekipo za osredotoˇcenost na cilje, organizira sestanke, preverja napredek ipd. Opazovalci so lahko prisotni le na dnevnih sestankih,
Diplomska naloga 11 prepovedano jim je kakrˇsno koli vmeˇsavanje v pogovor [8, 2].
Za metodologijo Scrum je znaˇcilno, da je vsaka izdaja programske opreme razdeljena na sprinte, celotno zaporedje akcij pa je predstavljeno na Sliki 2.3.
Dolˇzina sprinta lahko traja od enega tedna do enega meseca, najpogostejˇsa pa sta dva tedna. Vsak sprint se zaˇcne s sestankom, na katerem so predstavljene zgodbe, nekatere od teh pa so nato izbrane za realizacijo. Na sestanku so prisotni vsi ˇclani ekipe, da sprint izvedejo kar se da najboljˇse. Razvojna ekipa ima sestanek vsak dan, ki traja pribliˇzno 15 min. Na njem vsak ˇclan predstavi svoje napredke ter teˇzave, ki jih po sestanku poskuˇsajo reˇsiti. Enkrat ali veˇckrat na teden poteka sestanek tudi med razvojnimi ekipami. En ˇclan iz vsake skupine na kratko predstavi predhodno delo in njihov naˇcrt za naprej.
Vsak sprint se konˇca s pregledom, kjer opazijo napredek in napake, lastniku izdelka pa se predstavijo tudi rezultati [39, 2, 8]. Scrum uporablja veliko podobnih tehnik kot agilna metodologija XP, ima pa tudi svoje tehnike, kot so diagram izgorevanja, pregled sprinta, ocena sprinta ipd.
Slika 2.3: Zaporedje akcij v pristopu Scrum [38].
2.2.3 DevOps
DevOps je eden izmed najnovejˇsih naˇcinov za razvoj programske opreme, ki je nastal leta 2009 in dopolnjuje agilne pristope. Agilne pristope lahko obrav- navamo kot odpravljanje nejasnosti v komunikaciji med kupci in razvijalci, medtem ko DevOps poleg komunikacije med kupci in razvijalci obravnava tudi povezavo med razvijalci in skupino za podporo delovanju IT, da lahko hitreje in bolj zanesljivo gradijo, preizkuˇsajo in izdajajo programsko opremo.
DevOps tako predstavlja kombinacijo filozofij, praks in orodij, ki omogoˇca boljˇse sodelovanje med razliˇcnimi podroˇcji podjetja. Izraz DevOps je nastal z zdruˇzevanjem besed “razvoj”(ang. Dev – development) in “operacije”(ang.
Ops – operations), kar pomeni, da zdruˇzuje razvojne skupine in skupino za podporo delovanju IT, ki po navadi delujejo loˇceno. Organizacije DevOps hitreje razvijajo in izboljˇsujejo izdelke kot organizacije, ki uporabljajo tra- dicionalne procese razvoja programske opreme, to pa jim omogoˇca, da bolje sluˇzijo svojim strankam in uˇcinkoviteje konkurirajo na trgu. Beseda “Dev”
se uporablja kot okrajˇsava za razvijalce, katerih cilj je izdelovati novo pro- gramsko opremo oz. nove funkcije programske opreme. Beseda “Ops” pa se uporablja za IT podporo, ki jih vodi ˇzelja po stabilnosti programske opreme, ki so jo ponudili stranki. V Ops skupino spadajo sistemski inˇzenirji, sistemski skrbniki, omreˇzni inˇzenirji in varnostni inˇzenirji, ki skrbijo za npr. moˇcnejˇse streˇznike, boljˇso internetno povezavo, itd. Del Dev v DevOps-u temelji na agilnem pristopu, kjer uporabljajo veliko enakih praks kot pri pristopih XP in Scrum, npr. refaktoriranje kode, programiranje v paru, testiranje enot itd.
Temu pa je dodan ˇse del Ops, za katerega pa so znaˇcilne prakse, kot so npr.
zvezna postavitev, spremljanje aplikacij, avtomatizirane nadzorne ploˇsˇce ipd.
Celotno zaporedje akcij v pristopu DevOps je prikazano na Sliki 2.4
DevOps se nagiba predvsem k avtomatizaciji procesov, kar pomeni, da pristop odpravlja potrebo po roˇcnem posredovanju strokovnjakov in tako zmanjˇsa verjetnost za ˇcloveˇske napake [51, 52].
Diplomska naloga 13
Slika 2.4: DevOps (Zaporednje akcij v DevOps-u [19]).
2.3 Primerjava med agilnimi pristopi in pri- stopom DevOps
DevOps je naˇcin razvoja programske opreme, ki se osredotoˇca na razvoj pro- gramske opreme s pomoˇcjo avtomatizacije in komunikacije med razvijalci in skupino za podporo delovanju IT, medtem ko so agilni pristopi osredotoˇceni na razvoj programske opreme s pomoˇcjo povratnih informacij strank, da se lahko hitro odzovejo na stalno spreminjajoˇce potrebe strank. Na Sliki 2.5 je prikazana razlika med zaporedjem akcij pri agilnih pristopih in pristopu DevOps.
Nekaj kljuˇcnih razlik:
• Namen agilnih pristopov je razvijanje programske opreme s skupnimi prizadevanji samoorganizirajoˇcih razvojnih skupin ter njihovih strank.
DevOps daje enak poudarek na razvoj programske opreme in delovanje programske opreme.
• Agilni pristop vkljuˇcuje razvoj, testiranje, integracijo in uvajanje. Po dostavi izdelka ne izvaja nobenih operacij. DevOps poleg razvoja, testi- ranja, integracije, uvajanja vkljuˇcuje ˇse delovanje po uvajanju izdelka.
Pomembno je neprekinjeno spremljanje programske opreme, da se za- gotovi dobro delovanje izdelka.
• Agilne ekipe dobivajo povratne informacije od stranke, DevOps pa tako od stranke kot notranjih ekip.
• Pri agilnih pristopih ne poudarjajo avtomatizacije, pri DevOps-u je avtomatizacija nujna.
• Agilna metodologija, kot sta npr. Scrum in XP, zagovarjata iterativno uvajanje programske opreme po vsakem sprintu, DevOps pa nepreki- njeno dostavo vsak dan [32].
Slika 2.5: Primerja agilnih pristopov in pristopa DevOps (prirejeno po [36]).
Poglavje 3
Model kakovosti programske opreme ISO/IEC 25010
V tem poglavju bomo spoznali pojem model kakovosti programske opreme in predstavili model ISO/IEC 25010. Faktorje modela kakovosti ISO/IEC 25010 bomo nato uporabili tudi pri primerjavi kljuˇcnih praks v ˇcetrtem poglavju.
Model kakovosti programske opreme je osnova za ocenjevanje program- ske reˇsitve in opredeljuje faktorje kakovosti za ocenjevanje programskega iz- delka. Obstaja uveljavljeni standard kakovosti programske opreme ISO/IEC 25010, ki obsega osem lastnosti kakovosti, na katere bomo pozorni pri vplivu praks DevOps na kakovost programske opreme. ISO/IEC 25010 prihaja iz serije standardov ISO/IEC 25000, znane tudi kot SQuaRE (System and Soft- ware Quality Requirements and Evaluation), katerih namen je ustvariti okvir za oceno kakovosti programske opreme. Ce programski izdelek izpolnjujeˇ doloˇcene faktorje kakovosti, kot so npr. funkcionalnost, uˇcinkovitost ipd.
in zagotavlja doloˇceno vrednost, ima programski izdelek doloˇceno stopnjo kakovosti.
15
3.1 Faktorji kakovosti v modelu ISO/IEC 25010
Model kakovosti ISO/IEC 25010 opisuje osem faktorjev kakovosti program- ske opreme, vsak faktor pa je sestavljen iz podkategorij. Model kakovosti ISO/IEC 25010 je predstavljen na Sliki 3.1.
Slika 3.1: Model kakovosti ISO/IEC 25010 (prirejeno po [27]).
Funkcionalna ustreznost predstavlja stopnjo, do katere izdelek ali sistem zagotavlja funkcije, ki izpolnjujejo zastavljene potrebe, kadar se uporabljajo pod doloˇcenimi pogoji. Funkcionalna ustreznost je sestavljena iz:
• Funkcionalne primernosti – stopnja, do katere nabor funkcij pokriva vse predvidene naloge in uporabniˇske cilje.
• Funkcionalne pravilnosti – stopnja, do katere izdelek ali sistem zagota- vlja pravilne rezultate s potrebno stopnjo natanˇcnosti.
• Funkcionalne ustreznosti – stopnja, do katere funkcije olajˇsajo ure- sniˇcevanje doloˇcenih nalog in ciljev.
Uˇcinkovitost delovanja predstavlja uspeˇsnost glede na koliˇcino sredstev, ki se pojavijo v navedenih pogojih. Uˇcinkovitost delovanja je sestavljena iz:
• Casovnega obnaˇsanja – stopnja, do katere sistem pri opravljanju funkcijˇ izpolnjuje podane zahteve glede odzivnosti, ˇcasa obdelave in pretoˇcnosti izdelka.
Diplomska naloga 17
• Uporabe virov – stopnja, do katere sistem pri opravljanju svojih funkcij izpolnjuje zahteve glede koliˇcine in vrste virov, ki jih sistem uporablja.
• Zmogljivosti – stopnja, do katere sistem izpolnjuje zahteve glede najviˇsjih mejnih parametrov izdelka.
Zdruˇzljivost oz. kompatibilnost predstavlja stopnjo, do katere lahko iz- delek, sistem ali komponenta izmenjuje informacije z drugimi izdelki, sistemi ali komponentami in/ali izvaja zahtevane funkcije, medtem ko si deli isto strojno ali programsko okolje. Podkategoriji zdruˇzljivosti oz. kompatibilno- sti sta:
• Soobstoj – stopnja, do katere izdelek ˇse dovolj dobro opravlja zahtevane funkcije ob deljenju skupnega okolja in podatkov z drugimi izdelki. Po- membno je, da se izdelek dobro obnaˇsa in ne ˇskoduje drugim izdelkom.
• Interoperabilnost – stopnja, do katere lahko dva ali veˇc sistemov izme- njuje podatke oz. informacije in uporablja spremenjene informacije.
Uporabnost predstavlja stopnjo, do katere lahko uporabnik uˇcinkovito, zmogljivo in zadovoljivo uporabi izdelek za doseganje doloˇcenih ciljev v doloˇcenem kontekstu uporabe. Uporabnost je sestavljena iz:
• Prepoznavanja ustreznosti – stopnja, do katere lahko uporabniki pre- poznajo, ali je izdelek primeren za njihovo uporabo.
• Uˇcljivosti – stopnja, do katere izdelek ali sistem omogoˇca uporabniku, da se nauˇci, kako izdelek uporabljati uˇcinkovito in v izrednih razmerah.
• Operativnosti – stopnja, do katere izdelek omogoˇca enostavno upra- vljanje in nadzor.
• Zaˇsˇcite uporabnikov pred napakami – stopnja, do katere sistem ˇsˇciti uporabnike, da bi naredili napako.
• Estetike uporabniˇskega vmesnika – stopnja, do katere uporabniˇski vme- snik programske opreme omogoˇca prijetno interakcijo s stranko.
• Dostopnosti – stopnja, do katere ima izdelek zmoˇznost za dosego cilja v doloˇcenem kontekstu uporabe.
Zanesljivost predstavlja stopnjo, kjer raˇcunalniˇski izdelek ali komponenta izvaja doloˇcene funkcije pod doloˇcenimi pogoji za doloˇceno ˇcasovno obdobje.
Zanesljivost je sestavljena iz:
• Zrelosti – stopnja, do katere sistem izpolnjuje zahtevane potrebe pri normalnem delovanju.
• Razpoloˇzljivosti – stopnja, do katere sistem deluje in je dostopen, kadar ga uporabniki potrebujejo.
• Tolerance napak – stopnja, do katere izdelek kljub prisotnosti napak v strojni ali programski opremi deluje, kot je predvideno.
• Obnovljivosti – stopnja, do katere izdelek v primeru prekinitve obnovi podatke in ponovno vzpostavi ˇzeleno stanje sistema.
Varnost je stopnja, do katere sistem ˇsˇciti podatke, da lahko osebe ali pro- gramski izdelki dostopajo do podatkov samo do stopnje, do koder jim je to dovoljeno. Varnost je sestavljena iz:
• Zaupnosti – stopnja, do katere so podatki dostopni tistim, ki imajo dovoljenje za dostop.
• Integritete – stopnja, do katere programski izdelek prepreˇcuje nepoo- blaˇsˇcen dostop ali spreminjanje podatkov oz. programa.
• Nezatajljivosti – stopnja, do katere se lahko dokaˇze, da se je dogodek storil.
• Odgovornosti – stopnja, do katere so lahko akcije subjekta izsledljive le do subjekta.
• Pristnosti – stopnja, do katere se zagotavlja identiteta predmeta ali vira, ki zahteva dostop do doloˇcenih informacij ali dejanj.
Diplomska naloga 19 Vzdrˇzevanjeje stopnja, do katere se lahko izboljˇsata uˇcinkovitost in uspeˇsnost programske opreme s tem, da vzdrˇzevalci izdelek spremenijo, prilagodijo ali popravijo. Vzdrˇzevanje je sestavljeno iz:
• Modularnosti – stopnja, do katere je programski izdelek iz loˇcenih delov oz. komponent in tako spreminjanje ene komponente minimalno vpliva na spreminjanje druge komponente.
• Ponovne uporabnosti – stopnja, do katere se enota lahko uporabi v veˇc kot enem sistemu ali pri gradnji drugih enot.
• Moˇznosti analize – stopnja, do katere je mogoˇce uˇcinkovito in uspeˇsno oceniti vpliv predvidene spremembe na izdelek ali sistem na enem ali veˇc njegovih delih, ugotoviti slabosti izdelka ali prepoznati dele, ki jih je treba spremeniti.
• Spremenljivosti – stopnja, do katere lahko izdelek uˇcinkovito in uspeˇsno spremenimo, ne da bi pri tem priˇslo do napak ali poslabˇsanja kakovosti izdelka.
• Moˇznost preizkusa – stopnja, do katere je mogoˇce uspeˇsno in uˇcinkovito doloˇciti merila za preizkus izdelka in opraviti preizkuse, da se ugotovi, ali so ta merila izpolnjena.
Prenosljivost je stopnja, do katere lahko uˇcinkovito in uspeˇsno prenesemo program oz. izdelek iz ene strojne ali programske opreme v drugo. Preno- sljivost je sestavljena iz:
• Prilagodljivosti – stopnja, do katere je mogoˇce izdelek ali sistem uˇcinkovito in uspeˇsno prilagoditi razliˇcni oz. razvijajoˇci se strojni opremi, pro- gramski opremi ali drugemu okolju uporabe.
• Moˇznosti namestitve – stopnja, do katere lahko izdelek uspeˇsno in uˇcinkovito namestimo in odstranimo iz doloˇcenega okolja.
• Zamenljivosti – stopnja, do katere lahko izdelek v istem okolju nado- mesti drug doloˇcen programski izdelek za isti namen [27].
Poglavje 4
Kljuˇ cne prakse DevOps in njihov vpliv na faktorje
kakovosti po modelu ISO/IEC 25010
V tem poglavju so predstavljene kljuˇcne prakse DevOps in njihov vpliv na faktorje kakovosti po modelu ISO/IEC 25010.
Prakse smo izbrali z analiziranjem ˇclankov [29, 40, 10], kjer smo ugotovili, da so spodnje prakse omenjene v veˇcini ˇclankov, pomagali pa smo si tudi z dvema knjigama s podroˇcja DevOps [17, 45]. Prav tako smo z analizo ˇclankov iskali informacije o vplivu praks Devops na faktorje kakovosti po modelu ISO/IEC 25010. Na Sliki 4.1 so predstavljene kljuˇcne prakse DevOps in njihov pozitivni vpliv na faktorje kakovosti po modelu ISO/IEC 25010.
21
Slika 4.1: Pozitiven vpliv praks DevOps na faktorje kakovosti po modelu ISO/IEC 25010.
4.1 Aktivno sodelovanje strani udeleˇ zenih v razvoju programske opreme (angl. Ac- tive Stakeholder Participation)
Ena kljuˇcnih praks za DevOps je aktivno sodelovanje strani udeleˇzenih v ra- zvoju programske opreme. Praksa je nadgradnja XP-jeve prakse povratnih informacij strank v podjetju. Aktivno sodelovanje strani, udeleˇzenih v ra- zvoju programske opreme, pomeni, da morajo razvijalci tesno sodelovati s skupino za podporo delovanju IT in ne le s strankami. Priˇcakuje pa se, da je tudi skupina za podporo delovanju IT pripravljena tesno sodelovati z razvi- jalci. Strani, udeleˇzene v razvoju programske opreme, bi morale pravoˇcasno zagotavljati informacije, pravoˇcasno sprejemati odloˇcitve in biti tako aktivno vkljuˇcene v razvojni proces. ˇCe bodo strani udeleˇzenih v razvoju programske opreme dobro sodelovale, bodo rezultati zagotovo na visoki ravni, razvile pa se bodo tudi boljˇse programske reˇsitve [44, 37].
Sodelovanje strani, udeleˇzenih v razvoju programske opreme, bo zagoto- vilo veˇc povratnih informacij, ki so pomembne za uspeh izdelka. Izboljˇsa se
Diplomska naloga 23 komunikacija med ekipo, ki zagotavlja izdelek z boljˇso uˇcinkovitostjo delova- nja. Dobra komunikacija med razvijalci in skupini za podporo delovanju IT izboljˇsa tudi interoperabilnost (izmenjava podatkov med dvema ali veˇc sis- temi in uporabljanje spremenjenih informacij) oz. zdruˇzljivost izdelka [31].
4.2 Avtomatizirano testiranje (angl. Auto- mated Testing)
Avtomatizirano testiranje je praksa preizkuˇsanja programske opreme, ki se izvaja s pomoˇcjo posebnih programskih orodij za izvajanje zbirke testnih primerov brez roˇcnega posega. Avtomatizirano testiranje se uporablja tudi v drugih pristopih, ne le v DevOps-u. Programska oprema za avtomatizacijo lahko v testni sistem vnese testne podatke, primerja priˇcakovane in dejanske rezultate ter ustvari podrobna poroˇcila o preizkusih oz. testih. Neuspeli testi natanˇcno prikaˇzejo, kje se je napaka zgodila, razvijalci pa tako laˇzje najdejo in odpravijo napako v kodi. Praksa zahteva precejˇsnja vlaganja sredstev.
Testna avtomatizacija se uporablja za avtomatizacijo ponavljajoˇcih se nalog in drugih preizkusnih nalog, ki jih je teˇzko izvesti roˇcno. Avtomatizacija testiranj je ˇse posebej uporabna, ker omogoˇca hitrejˇse izvajanje ˇzivljenjskega cikla razvoja programske opreme in pomaga zgodaj odkriti teˇzave ali napake v razvojni fazi, kar poveˇca uˇcinkovitost ekipe. Avtomatizirano testiranje ni primerno za pogosto se spreminjajoˇce testne primere. Z avtomatizacijo postopka testiranja razvojna ekipa porabi manj ˇcasa za preverjanje novo razvitih funkcij in zmanjˇsa poslovne stroˇske. Avtomatizirano preizkuˇsanje programske opreme ne daje samo vpogleda v izdelek, temveˇc tudi prikazuje vsebino pomnilnika, podatkovne tabele, vsebino datotek in druga notranja stanja programa. To razvijalcem pomaga ugotoviti, kaj je ˇslo narobe. Cilj avtomatiziranega testiranja je zmanjˇsanje ˇstevila testnih primerov, ki jih je treba izvesti roˇcno [45, 48, 41, 55].
Okolje DevOps pomeni avtomatizacijo procesov in orodij, sama avtoma- tizacija pa je kljuˇcni dejavnik uspeha pri zagotavljanju kakovosti programske
opreme. Avtomatizacija pozitivno vpliva na zagotavljanje zanesljivosti, saj se napake pri testiranju odkrijejo in jih nato programerji laˇzje odpravijo.
Avtomatizirano testiranje pa vpliva tudi na vzdrˇzevanje, saj je napisane te- ste mogoˇce ponovno uporabiti pri kakˇsnih drugih sistemih, kjer se uporablja enaka oz. podobna funkcionalnost [31, 33, 46]. Avtomatizirano testiranje pomaga tudi pri razvoju uˇcinkovite programske opreme [33].
Diplomska naloga 25
4.3 Integrirano upravljanje konfiguracije (angl.
Integrated Configuration Management)
Integrirano upravljanje konfiguracije je praksa sistemskega inˇzenirstva za vzpostavitev in vzdrˇzevanje skladnosti delovanja, funkcionalnih in fiziˇcnih lastnosti izdelka z njegovimi zahtevami, zasnovo in operativnimi informaci- jami v celotni ˇzivljenjski dobi. Upravljanje konfiguracije je oblika upravljanja storitev, ki zagotavlja, da so konfiguracije sistemskih virov, raˇcunalniˇskih sis- temov, streˇznikov in drugih sredstev znane, dobre in zanesljive. Ta okolja je treba skrbno upravljati, vsem spremembam konfiguracije pa je treba slediti, da se zagotovi njihova sledljivost [14]. Za doseganje teh ciljev upravljanje kon- figuracije veˇcinoma vkljuˇcuje visoko stopnjo avtomatizacije. Praksa ima veˇc prednosti, kot sta npr. poenostavitev namestitve novega okolja, zmanjˇsanje tveganj, povezanih s konfiguracijo proizvodnega okolja ipd. Praksa omogoˇca tudi konfiguriranje vseh okolij iz centralnega mesta ter natanˇcno izdelavo no- vega enakega okolja s pravilnimi konfiguracijami in programsko opremo, saj je poznana konfiguracija prvotnega okolja [18, 44, 30, 49].
Cilj je vzdrˇzevanje teh sistemov v znanih, doloˇcenih stanjih. Drug vidik sistema za upravljanje konfiguracije je opis ˇzelenega stanja sistemov. Tretji glavni vidik sistema za upravljanje konfiguracije je programska oprema za avtomatizacijo, ki skrbi za vzdrˇzevanje ciljnih sistemov in programske opreme v ˇzelenem stanju [18, 44, 30, 49]. Avtomatizacija upravljanja konfiguracije izboljˇsa zanesljivost in uˇcinkovitost delovanja ter vzdrˇzevanje, ker se postopki roˇcne konfiguracije nadomestijo z avtomatiziranimi procesi, konfiguracije pa je mogoˇce ponovno uporabiti [26, 15, 31].
4.4 Integrirano upravljanje sprememb (angl.
Integrated Change Management)
Upravljanje sprememb je skupni izraz za vse pristope k pripravi, podpori in pomoˇci posameznikom, ekipam in organizacijam pri izvajanju organizacij-
skih sprememb. Upravljanje sprememb vkljuˇcuje zajem in pripravo zahtev za spremembe, naˇcrtovanja, izvajanja in ocenjevanja sprememb, ki so potrebne za izpolnitev novih zahtev. Praksa zajema pripravo in podporo zaposlenim, doloˇcitev potrebnih korakov za spremembe ter spremljanje dejavnosti pred in po spremembah, da se zagotovi uspeˇsno izvajanje. V kontekstu upravljanja projektov se lahko izraz ”upravljanje sprememb”uporablja kot alternativa izrazu ”nadzor sprememb”. Praksa pomaga usmerjati in usklajevati spre- membe za boljˇso programsko opremo [11, 12].
Naˇcrt upravljanja sprememb ekipi omogoˇca, da prepozna zahtevane spre- membe ter te spremembe izvede. Pri pregledu literature smo ugotovili, da praksa pozitivno vpliva na tri faktorje kakovosti programske opreme in to so zanesljivost, varnost in uˇcinkovitost delovanja programske opreme [42, 43].
4.5 Zvezna integracija (angl. Continuous In- tegration)
Zvezna integracija je bila popularizirana v poznih devetdesetih kot del ek- stremnega programiranja, sedaj pa se praksa med drugimi uporablja tudi v Scrum-u in DevOps-u. Zvezna integracija je praksa razvoja programske opreme, pri kateri razvijalci redno zdruˇzujejo svoje spremembe kode v osre- dnji repozitorij, po navadi veˇckrat dnevno. To doseˇzemo z avtomatskimi orodji za doseganje zvezne integracije. Sistem za integracijo je dopolnjen tudi z drugimi preverjanji, kot so avtomatizirani preizkusi kakovosti kode, orodja za pregled sintakse ipd., ki potrdijo pravilnost nove kode pred inte- gracijo. Cilj je izogniti se vrstam integracijskih teˇzav, ki izhajajo iz velikih, redkih zdruˇzitev kode.
Zvezna integracija pozitivno vpliva na produktivnost ekipe in uˇcinkovitost delovanja. Zvezna integracija ima pozitiven vpliv na vzdrˇzevanje, saj je bila koda preizkuˇsena z avtomatiziranimi testi in v primeru, da so se testi uspeˇsno izvedli, lahko razvijalec kodo ponovno uporabi [45, 24, 13, 50]. Avtomati- zirano testiranje nam omogoˇca, da hitreje najdemo in odpravimo napake,
Diplomska naloga 27 veˇcina napak pa je v postopku integracije ˇze odkritih. Posledica avtomatiza- cije je veˇcja kakovost (in zanesljivost) programske opreme [31, 16].
4.6 Zvezna postavitev (angl. Continuous De- ployment)
Zvezna postavitev je praksa, ki razˇsirja prakso zvezne integracije in z avto- matiziranim testiranjem preveri, ali je napisana programska koda pravilna za takojˇsnjo samostojno postavitev v proizvodno okolje. Zvezna postavitev omogoˇca razvojnim skupinam, da skrajˇsajo ˇcas med prepoznavanjem nove funkcije in njeno postavitvijo v proizvodno okolje. Organizacijam omogoˇca, da so bolj odzivne, poveˇcuje pa tveganje s poveˇcanjem moˇznosti za pojav napak v proizvodnji, kadar razvojne skupine niso dovolj disciplinirane. Za uspeˇsno zvezno postavitev v poslovnem okolju so potrebne vse prej opisane tehnike [44]. V postopku zvezne postavitve se koda samodejno uvede v proi- zvodno okolje, ko uspeˇsno opravi vse preizkusne primere v avtomatiziranem testiranju in preverjanju kakovosti [1, 18, 45].
Dobra stran zvezne postavitve je, da razvijalci od stranke dobijo povra- tne informacije v zelo kratkem ˇcasu. Avtomatizacija je povezana tudi s po- stopkom zvezne postavitve, praksa pa izboljˇsa zanesljivost, vzdrˇzevanje in varnost. Praksa zvezne postavitve pa poleg kakovostne programske opreme nudi ˇse izboljˇsano produktivnost in uspeˇsnost razvijalcev ter veˇcje zadovolj- stvo strank, saj stranke skoraj vsak dan vidijo nov izdelek [31].
4.7 Spremljanje (angl. Monitoring)
Spremljanje je praksa, ki vkljuˇcuje spremljanje celotnega razvojnega procesa, od naˇcrtovanja, razvoja, integracije in testiranja do postavitve in delovanja.
Vkljuˇcuje popoln pregled stanja aplikacij, storitev in infrastrukture v proi- zvodnem okolju v realnem ˇcasu. Funkcije, kot so spremljanje v realnem ˇcasu,
ogledi za nazaj in vizualizacije, so kljuˇcne komponente spremljanja aplikacij in storitev.
Ekipe DevOps s pomoˇcjo spremljanja pridobivajo povratne informacije iz produkcijskih okolij ter se tako hitro in samodejno odzovejo na vsako slabo uporabniˇsko izkuˇsnjo [34]. Obstajajo razliˇcne vrste spremljanja, kot so spremljanje infrastrukture, spremljanje aplikacije in spremljanje omreˇzja [35]. S pomoˇcjo spremljanja lahko podjetje poveˇca uˇcinkovitost delovanja in varnost programskih reˇsitev [25]. Spremljanje pa naj bi pozitivno vplivalo tudi na zanesljivost [31].
Poglavje 5
Vpliv praks DevOps na
kakovost po modelu ISO/IEC 25010 v slovenskih MSP
Izvedli smo anketo, kjer smo ugotavljali, kakˇsen je vpliv praks DevOps na faktorje kakovosti v slovenskih malih in srednje velikih podjetjih, ki delajo skladno z metodologijo DevOps. Na anketo je odgovorilo 73 razvijalcev iz razliˇcnih podjetij, od teh jih je 16 anketo reˇsilo le delno. Pri analizi smo zato lahko upoˇstevali 57 celotno reˇsenih anket.
Analiza ankete je pokazala, da je 68 % anketirancev oz. razvijalcev v okviru tipiˇcnega projekta izdelovalo novo programsko opremo, 25 % raz- vijalcev prilagojeno standardno programsko reˇsitev, ostalih 7 % pa druge programske tipe kot so erp, poc ipd.
68 % razvijalcev je razvijalo projekt za notranjega naroˇcnika, ostalih 32
% pa za zunanjega naroˇcnika oz. s pomoˇcjo kakˇsne programerske hiˇse.
10 razvijalcev je odgovorilo, da je bilo v okviru njihovega tipiˇcnega pro- jekta prisotnih 6 ˇclanov projektne ekipe, 9 pa jih je poroˇcalo, da je bila njihova skupina 7-ˇclanska. Na Sliki 5.1 pa so prikazane frekvence ostalih velikosti skupin.
Anketa je pokazala, da je najveˇc razvijalcev sodelovalo v projektu, ki je bil 29
Slika 5.1: ˇStevilo ˇclanov v projektni ekipi.
vreden med 250.000 in 500.000 evri, sledijo mu projekti, vredni med 50.000 in 100.000 evri, najmanj razvijalcev pa je sodelovalo v projektih draˇzjih od 1.000.000 evrov.
Slika 5.2: Pribliˇzna vrednost celotnega stroˇska projektov.
Veˇcina projektov je trajala med 6 in 12 oz. 12 in 18 mesecev, najmanj projektov pa je trajalo 18–24 mesecev in manj kot 3 mesece.
Diplomska naloga 31
Slika 5.3: ˇCas trajanja projekta.
Na Sliki 5.4 je predstavljeno, kaj anketiranci mislijo, katera praksa De- vOps bistveno pripomore k izboljˇsanju faktorja kakovosti. Barve polja smo doloˇcili glede na povpreˇcno oceno prakse pri vplivu na faktor kakovosti.
Vrednost : barva polja
• Do 2,25 : temno rdeˇca
• Od 2,25 do 2,75 : rdeˇca
• Od 2,75 do 3,25 : oranˇzna
• Od 3,25 do 3,75 : rumena
• Od 3,75 do 4,25 : zelena
• Od 4,25 naprej : temno zelena
Slika 5.4: Mnenje slovenskih razvijalcev v malih in srednje velikih podjetjih o praksah DevOps in njihovem pozitivnem vplivu na faktorje kakovosti.
Anketiranci menijo, da praksa avtomatizirano testiranje najbolj izboljˇsa zanesljivost programske opreme. Integrirano upravljanje konfiguracije, zve- zna integracija in zvezna postavitev najbolj izboljˇsajo vzdrˇzevanje, spre- mljanje pa naj bi po mnenju anketirancev najbolj pozitivno vplivalo na uˇcinkovitost delovanja in zanesljivost.
Anketiranci menijo, da aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme bistveno ne pripomore k nobenemu faktorju kakovosti programske opreme, ˇse vedno pa ima izmed vseh faktorjev najveˇcji vpliv na zdruˇzljivost oz. kompatibilnost.
Rezultati ankete so pokazali, da avtomatizirano testiranje najbolj izboljˇsa zanesljivost programske opreme, najslabˇsi vpliv pa ima na prenosljivost.
Integrirano upravljanje konfiguracije naj bi po mnenju anketirancev iz- boljˇsalo vzdrˇzevanje programske opreme, najslabˇsi vpliv pa ima na uporab- nost.
Mnenje anketirancev o integriranem upravljanju sprememb je, da bi- stveno ne izboljˇsa nobenega faktorja kakovosti programske opreme, ˇse ve- dno pa najbolj pozitivno vpliva na vzdrˇzevanje programske reˇsitve. Najmanj
Diplomska naloga 33 pozitivnega vpliva ima praksa na prenosljivost programske reˇsitve.
Zvezna integracija najbolj pripomore k izboljˇsanju vzdrˇzevanja program- ske opreme, najmanjˇsi pozitivni vpliv pa ima praksa na uporabnosti pro- gramske opreme.
Mnenje anketirancev o zvezni postavitvi je, da najbolj pripomore k vzdrˇzevanju programske opreme, najmanj pa naj bi praksa pripomogla k funkcionalni ustreznosti.
Spremljanje po mnenju anketirancev bistveno pripomore k uˇcinkovitosti delovanja in zanesljivosti programske opreme, najmanj pa spremljanje pripo- more k prenosljivosti programske opreme.
5.1 Primerjava vpliva praks DevOps na fak- torje kakovosti med cenejˇ simi in draˇ zjimi projekti
Analizo ankete smo nadgradili s primerjavo, ali se rezultati statistiˇcno znaˇcilno razlikujejo glede na vrednost projekta. Projekte smo razdelili v dve pribliˇzno enaki skupini, in sicer v cenejˇse in draˇzje. Cenejˇsih projektov je bilo 30, draˇzjih pa 27.
Cenejˇsi projekti:
• Manj kot 50.000 e
• Med 50.000 e in 100.000 e
• Med 100.000 e in 250.000 e Draˇzji projekti:
• Med 250.000 e in 500.000e
• Med 500.000 e in 1.000.000e
• Veˇc kot 1.000.000 e
Na Sliki 5.5 in 5.6 lahko opazite razliko, kako so anketiranci, ki so so- delovali v cenejˇsih projektih odgovarjali, kako prakse pozitivno vplivajo na faktorje kakovosti v primerjavi z anketiranci, ki so sodelovali v draˇzjih pro- jektih.
Diplomska naloga 35
Slika 5.5: Mnenje anketirancev o praksah DevOps in njihovem pozitivnem vplivu na faktorje kakovosti pri cenejˇsih projektih.
Slika 5.6: Mnenje anketirancev o praksah DevOps in njihovem pozitivnem vplivu na faktorje kakovosti pri draˇzjih projektih.
Pred izvedbo vseh nadaljnjih testov smo preverili koeficienta asimetrije in sploˇsˇcenosti, veˇcina spremenljivk je priˇslo med -2 in +2 [22]. Ker smo ugo- tovili, da nekateri od parametrov niso normalno porazdeljeni, smo pri vseh
testih uporabili Mann-Whitneyev U test.
Hipoteza: Med cenejˇsimi in draˇzjimi projekti obstajajo statistiˇcno znaˇcilne razlike glede na vpliv praks na faktorje kakovosti programske opreme.
Pri Mann-Whitneyevim U testu so bile vse porazdelitve pribliˇzno enake oblike, zato smo lahko primerjali mediane med cenejˇsimi in draˇzjimi pro- jekti. Podobnost oblik pa smo preverili s Kolmogorov-Smirnovim testom.
Do statistiˇcne znaˇcilnosti (p ≤ 0,05) pri Mann-Whitneyevim U testom pri- haja v enem primeru:
• Integrirano upravljanje konfiguracije bistveno pripomore k uˇcinkovitosti delovanja programske reˇsitve. Integrirano upravljanje konfiguracije se je pri draˇzjih projektih izkazalo kot pomembnejˇse v prispevku k uˇcinkovitosti delovanja programske reˇsitve kot pa pri cenejˇsih projek- tih.
Pri zgornjem primeru smo hipotezo potrdili, pri ostalih pa ovrgli.
5.2 Primerjava vpliva praks DevOps na fak- torje kakovosti glede na ˇ cas trajanja pro- jekta
Poleg vrednosti projekta pa smo ugotavljali tudi, ali se vpliv praks DevOps na faktorje kakovosti razlikuje tudi glede na trajanje projekta. Projekte smo razdelili v dve skupini, krajˇsih projektov je bilo 37, daljˇsih pa 20.
Krajˇsi projekti:
• Manj kot 3 mesece
• Med 3 in 6 mesecev
• Med 6 in 12 mesecev
Diplomska naloga 37
• Med 12 in 18 mesecev Daljˇsi projekti:
• Med 18 in 24 mesecev
• Med 24 in 30 mesecev
• Med 30 in 36 mesecev
• Veˇc kot 36 mesecev
Na Sliki 5.7 in 5.8 lahko opazite razliko, kako so anketiranci, ki so sodelo- vali v krajˇsih projektih odgovarjali, kako prakse pozitivno vplivajo na faktorje kakovosti v primerjavi z anketiranci, ki so sodelovali v daljˇsih projektih.
Slika 5.7: Mnenje anketirancev o praksah DevOps in njihovem pozitivnem vplivu na faktorje kakovosti pri krajˇsih projektih.
Slika 5.8: Mnenje anketirancev o praksah DevOps in njihovem pozitivnem vplivu na faktorje kakovosti pri daljˇsih projektih.
Hipoteza: Med krajˇsimi in daljˇsimi projekti obstajajo statistiˇcno znaˇcilne razlike glede na vpliv praks na faktorje kakovosti programske opreme.
Znotraj skupine krajˇsih projektov odgovori odstopajo od normalne porazde- litve pri dveh postavkah, zato smo tudi tukaj za primerjavo skupin uporabili Mann-Whitneyev U test.
Do statistiˇcne znaˇcilnosti (p ≤ 0,05) pri Mann-Whitneyevim U testom pri- haja v osmih primerih:
• Aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, bistveno pripomore k uˇcinkovitosti delovanja programske reˇsitve. Pri krajˇsih projektih se bolj strinjajo, da aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, bistveno pripomore k uˇcinkovitosti de- lovanja programske reˇsitve, kot v skupini daljˇsih projektov.
• Aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, bistveno pripomore h kompatibilnosti programske reˇsitve. V skupini ˇcasovno krajˇsih projektov se bolj strinjajo s tem, da aktivno sodelovanje
Diplomska naloga 39 strani, udeleˇzenih v razvoju programske opreme, bistveno pripomore h kompatibilnosti programske reˇsitve kot v skupini daljˇsih projektov.
• Aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, bistveno pripomore k prenosljivosti programske reˇsitve. Pri krajˇsih projektih se bolj strinjajo, da aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, bistveno pripomore k prenosljivosti pro- gramske reˇsitve kot pa pri daljˇsih projektih.
• Avtomatizirano testiranje bistveno pripomore k varnosti programske reˇsitve. Pri krajˇsih projektih se bolj strinjajo, da avtomatizirano te- stiranje bistveno pripomore k varnosti programske reˇsitve kot pa pri daljˇsih projektih.
• Integrirano upravljanje konfiguracije bistveno pripomore k uˇcinkovitosti delovanja programske reˇsitve. V skupini ˇcasovno daljˇsih projektov se bolj strinjajo s tem, da integrirano upravljanje konfiguracije bistveno pripomore k uˇcinkovitosti delovanja programske reˇsitve kot v skupini krajˇsih projektov.
• Integrirano upravljanje sprememb bistveno pripomore k prenosljivosti programske reˇsitve. Pri krajˇsih projektih se bolj strinjajo, da integri- rano upravljanje sprememb bistveno pripomore k prenosljivosti pro- gramske reˇsitve kot pri daljˇsih projektih.
• Spremljanje bistveno pripomore k uporabnosti programske reˇsitve. Pri daljˇsih projektih se bolj strinjajo, da spremljanje bistveno pripomore k uporabnosti programske reˇsitve kot pa pri krajˇsih.
• Spremljanje bistveno pripomore k vzdrˇzevanju programske reˇsitve. Pri krajˇsih projektih se bolj strinjajo, da spremljanje bistveno pripomore k vzdrˇzevanju programske reˇsitve kot pa pri daljˇsih projektih.
Pri zgornjih osmih primerih smo hipotezo potrdili, pri ostalih pa ovrgli.
5.3 Primerjava vpliva praks DevOps na fak- torje kakovosti glede na ˇ stevilo ˇ clanov v projektni ekipi
Vpliv praks DevOps na faktorje kakovosti programske opreme pa smo pri- merjali tudi glede na ˇstevilo ˇclanov v projektni ekipi. Projekte smo razdelili v dve pribliˇzno enaki skupini, in sicer v prvo skupino smo dali vse projekte, kjer je sodelovalo do vkljuˇcno 7 razvijalcev in teh projektov je 32, v drugo skupino pa vse projekte, kjer je sodelovalo veˇc kot 7 razvijalcev in teh projektov je 25.
Na Sliki 5.9 in 5.10 lahko opazite razliko, kako so anketiranci, ki so sodelo- vali v projektih, kjer je sodelovalo do vkljuˇcno 7 razvijalcev odgovarjali, kako prakse pozitivno vplivajo na faktorje kakovosti v primerjavi z anketiranci, ki so sodelovali v projektih, kjer je sodelovalo veˇc kot 7 razvijalcev.
Slika 5.9: Mnenje anketirancev o praksah DevOps in njihovem pozitivnem vplivu na faktorje kakovosti pri projektih do vkljuˇcno 7 razvijalcev.
Diplomska naloga 41
Slika 5.10: Mnenje anketirancev o praksah DevOps in njihovem pozitivnem vplivu na faktorje kakovosti pri projektih, kjer je sodelovalo veˇc kot 7 razvi- jalcev.
Hipoteza: Med projekti do vkljuˇcno 7 razvijalcev in projekti z veˇc kot 7 razvijalci obstajajo statistiˇcno znaˇcilne razlike glede na vpliv praks na fak- torje kakovosti programske opreme.
Ker tudi tukaj nekatere porazdelitve niso normalno porazdeljene, smo skupini primerjali z Mann-Withneyevim U testom, kjer smo med skupinama primer- jali mediani, saj so skupine, ki smo jih primerjali, imele pribliˇzno enako obliko porazdelitve.
Do statistiˇcne znaˇcilnosti (p ≤ 0,05) pri Mann-Withneyevim U testom pri- haja v sedmih primerih:
• Aktivno sodelovanje strani udeleˇzenih v razvoju programske opreme bistveno pripomore k funkcionalni ustreznosti programske reˇsitve. Pri projektih z manj razvijalci se bolj kot v projektih z veˇc razvijalci stri- njajo, da aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, pripomore k funkcionalni ustreznosti programske reˇsitve.
• Aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, bistveno pripomore k uˇcinkovitosti delovanja programske reˇsitve. Pri projektih z manj razvijalci se bolj kot v projektih z veˇc razvijalci stri- njajo, da aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, pripomore k uˇcinkovitosti programske reˇsitve.
• Aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, bistveno pripomore k prenosljivosti programske reˇsitve. Pri projektih z manj razvijalci se bolj kot v projektih z veˇc razvijalci strinjajo, da aktivno sodelovanje strani, udeleˇzenih v razvoju programske opreme, pripomore k prenosljivosti programske reˇsitve.
• Avtomatizirano testiranje bistveno pripomore k zanesljivosti program- ske reˇsitve. Pri projektih z manj razvijalci se bolj kot v projektih z veˇc razvijalci strinjajo, da avtomatizirano testiranje pripomore k zaneslji- vosti programske reˇsitve.
• Avtomatizirano testiranje bistveno pripomore k vzdrˇzevanju program- ske reˇsitve. Pri projektih z manj razvijalci se bolj kot v projektih z veˇc razvijalci strinjajo, da avtomatizirano testiranje pripomore k vzdrˇzevanju programske reˇsitve.
• Zvezna postavitev bistveno pripomore k vzdrˇzevanju programske reˇsitve.
Pri projektih z manj razvijalci se v veˇcji meri kot pri projektih z veˇc raz- vijalci strinjajo, da zvezna postavitev bistveno pripomore k vzdrˇzevanju programske reˇsitve.
• Spremljanje bistveno pripomore k vzdrˇzevanju programske reˇsitve. Pri projektih z manj razvijalci se bolj kot pri projektih z veˇc razvijalci strinjajo s tem, da spremljanje bistveno pripomore k vzdrˇzevanju pro- gramske reˇsitve.
Pri zgornjih sedmih primerih smo hipotezo potrdili, pri ostalih pa ovrgli.
Poglavje 6 Zakljuˇ cek
Ce povzamemo celotno diplomsko delo, smo najprej podrobno predstaviliˇ besedo agilnost, dva agilna pristopa, XP in Scrum, ter pristop DevOps kot nadgradnjo agilnih pristopov in tako ugotovili kljuˇcne razlike med njimi.
Predstavili smo model kakovosti ISO/IEC 25010 in osem pripadajoˇcih fak- torjev kakovosti, ki nam pomagajo ocenjevati izdelano programsko opremo.
V ˇcetrtem poglavju smo s pomoˇcjo ˇclankov in knjig analizirali kljuˇcne prakse DevOps, poleg tega pa smo poskuˇsali ugotoviti tudi, na kateri faktor kakovo- sti po modelu ISO/IEC 25010 vpliva doloˇcena praksa. Za vsako prakso smo naˇsli pozitivne vplive na faktorje kakovosti. Iz pregleda literature smo ugoto- vili, da aktivno sodelovanje strani udeleˇzenih v razvoju PO najbolj pozitivno vpliva na uˇcinkovitost delovanja in zdruˇzljivost, avtomatizirano testiranje, integrirano upravljanje in zvezna integracije konfiguracije najbolj pozitivno vplivajo na uˇcinkovitost delovanja, zanesljivost in vzdrˇzevanje, integrirano upravljanje sprememb najbolj pozitivno vpliva na zanesljivost, varnost in uˇcinkovitost delovanja, zvezna postavitev najbolj pozitivno vpliva na zane- sljivost, varnost in vzdrˇzevanje, spremljanje pa najbolj pozitivno vpliva na uˇcinkovitost delovanja, zanesljivost in varnost. Ugotovili smo, da je DevOps vsekakor dober naˇcin za izdelavo kakovostne programske opreme. Na koncu smo izdelali anketo, na katero so odgovarjali razvijalci DevOps. Analiza an- kete je pokazala, da so se rezultati anketirancev v veliki meri pribliˇzali rezul-
43
tatom, pridobljenimi v ˇclankih. Analizo ankete smo nadgradili s primerjavo med cenejˇsimi in draˇzjimi projekti, krajˇsimi in daljˇsimi projekti, projekti z manjˇsim ˇstevilom razvijalcev in projekti z veˇcjim ˇstevilom razvijalcem, kjer smo ugotavljali, ali med skupinami prihaja do razlik glede na vpliv praks De- vOps na faktorje kakovosti. Pri primerjavi med cenejˇsimi in draˇzjimi projekti je priˇslo do statistiˇcne znaˇcilnosti pri vplivu integriranega upravljanja konfi- guracije na uˇcinkovitost delovanja. Do statistiˇcnih znaˇcilnosti pri primerjavi projektov glede na ˇcas trajanja je priˇslo pri vplivu aktivnega sodelovanja strani udeleˇzenih v razvoju programske opreme na uˇcinkovitost delovanja, kompatibilnosti oz. zdruˇzljivosti in prenosljivosti, pri vplivu avtomatizira- nega testiranja na varnost, pri vplivu integriranega upravljanja konfiguracije na uˇcinkovitost delovanja, pri vplivu integriranega upravljanja sprememb na prenosljivost ter pri vplivu spremljanja na uporabnost in vzdrˇzevanje.
Pri zadnji primerjavi, kjer smo primerjali projekte glede na ˇstevilo ˇclanov v projektni ekipi, je priˇslo do statistiˇcne znaˇcilnosti pri vplivu aktivnega so- delovanja strani udeleˇzenih v razvoju programske opreme na funkcionalno ustreznost, uˇcinkovitost delovanja in prenosljivosti, pri vplivu avtomatizira- nega testiranja na zanesljivost in vzdrˇzevanje, pri vplivu zvezne postavitve na vzdrˇzevanje ter pri vplivu spremljanja na vzdrˇzevanje. Skratka, v pri- meru razvoja programske opreme s pristopom DevOps, se praksa zelo dobro pokriva s teorijo.
Diplomska naloga 45
Literatura
[1] 8 best practices for successful implementation of devops in your enterprise. Dosegljivo: https://dev.to/credencys/8-best- practices-for-successful-implementation-of-devops-in-your- enterprise-2k93, 2019. [Dostopano: 12. 11. 2020].
[2] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, and Juhani Warsta.
Agile software development methods: Review and analysis. arXiv pre- print arXiv:1709.08439, 2017.
[3] Adopting Agile: The Latest Reports About The Popular Mindset. Dose- gljivo: https://adevait.com/blog/remote-work/adopting-agile- the-latest-reports-about-the-popular-mindset, 2019. [Dosto- pano: 6. 6. 2021].
[4] Agile Methodology: An Overview. Dosegljivo: https://zenkit.com/
en/blog/agile-methodology-an-overview/, 2018. [Dostopano: 4. 6.
2020].
[5] Agile Methods of Software Development. Dosegljivo: http://www- public.imtbs-tsp.eu/~gibson/Teaching/Agile/AgileMethods.
pdf, 2011. [Dostopano: 4. 6. 2020].
[6] Agile software development. Dosegljivo: https://en.wikipedia.org/
wiki/Agile_software_development, 2021. [Dostopano: 22. 2. 2021].
47
[7] Agilne metode razvoja programske opreme. Dosegljivo: https://sl.
wikipedia.org/wiki/Agilne_metode_razvoja_programske_opreme, 2017. [Dostopano: 2. 6. 2020].
[8] Suleyman Akbas. Suitability of agile methodology in globally distributed soft-ware development: A case study. Computer Science, 59:3, 2019.
[9] Gloria Arcos Medina and David Mauricio. Aspects of software quality applied to the process of agile software development: a systematic lite- rature review. International Journal of System Assurance Engineering and Management, 10, 08 2019.
[10] Ineta Bucena and M. Kirikova. Simplifying the devops adoption process.
In BIR Workshops, 2017.
[11] Change management. Dosegljivo: https://en.wikipedia.org/wiki/
Change_management, 2021. [Dostopano: 30. 3. 2021].
[12] Software Change Management. Dosegljivo: https://www.drdobbs.
com/software-change-management/184415707, 2021. [Dostopano: 30.
3. 2021].
[13] Continuous Integration. Dosegljivo: https://www.agilealliance.
org/glossary/continuous-integration/, 2020. [Dostopano: 19. 7.
2020].
[14] What Is Configuration Management and Why Is It Important?
Dosegljivo: https://www.upguard.com/blog/5-configuration- management-boss, 2021. [Dostopano: 30. 3. 2021].
[15] What Is Configuration Management? Dosegljivo: https://www.
netapp.com/devops-solutions/configuration-management/what- is-configuration-management/, 2021. [Dostopano: 30. 3. 2021].
Diplomska naloga 49 [16] Continuous delivery: Huge benefits, but challenges too. Dosegljivo:
https://www.infoq.com/articles/cd-benefits-challenges/, 2015. [Dostopano: 17. 11. 2020].
[17] Jennifer Davis and Ryn Daniels. Effective DevOps: building a culture of collaboration, affinity, and tooling at scale. ”O’Reilly Media, Inc.”, 2016.
[18] Jennifer Davis and Ryn Daniels. Effective DevOps: building a culture of collaboration, affinity, and tooling at scale. ”O’Reilly Media, Inc.”, 2016.
[19] DevOps in a Scaling Environment. Dosegljivo: https://medium.com/
tech-tajawal/devops-in-a-scaling-environment-9d5416ecb928, 2020. [Dostopano: 8. 9. 2020].
[20] Extreme programming. Dosegljivo: https://en.wikipedia.org/
wiki/Extreme_programming, 2020. [Dostopano: 11. 6. 2020].
[21] Martin Fowler, Jim Highsmith, et al. The agile manifesto. Software Development, 9(8):28–35, 2001.
[22] Darren George. SPSS for windows step by step: A simple study guide and reference, 17.0 update, 10/e. Pearson Education India, 2011.
[23] Steve Hayes and Martin Andrews. An introduction to agile me- thods. Steve Hayes (Khatovar Technology) steve@ khatovartech. com http://www. khatovartech. com, 2002.
[24] Amran Hossain. Enhancing software quality using agile techniques.
IOSR Journal of Computer Engineering, 10:87–93, 01 2013.
[25] How devops increases security, not hurts it. Dosegljivo: https://
stackify.com/devops-security/, 2017. [Dostopano: 17. 11. 2020].
[26] Infrastructure as code. Dosegljivo: https://en.wikipedia.org/wiki/
Infrastructure_as_code, 2020. [Dostopano: 16. 11. 2020].
[27] ISO/IEC 25010. Dosegljivo: https://iso25000.com/index.php/
en/iso-25000-standards/iso-25010?limit=3&limitstart=0, 2019.
[Dostopano: 19. 6. 2020].
[28] Iteration Planning. Dosegljivo: http://www.extremeprogramming.
org/rules/iterationplanning.html, 1999. [Dostopano: 5. 6. 2020].
[29] R. Jabbari, N. Ali, K. Petersen, and B. Tanveer. What is devops?: A systematic mapping study on definitions and practices. Proceedings of the Scientific Workshop Proceedings of XP2016, 2016.
[30] Lesson 17: Configuration management. Dosegljivo: https:
//devopsbootcamp.osuosl.org/configuration-management.html#
id3, 2017. [Dostopano: 10. 11. 2020].
[31] Alok Mishra and Ziadoon Otaiwi. Devops and software quality: A sys- tematic mapping. Computer Science Review, 38:100308, 2020.
[32] Sikender Mohsienuddin Mohammad. Devops automation and agile me- thodology. SSRN Electronic Journal, 5:946–949, 08 2017.
[33] Sikender Mohsienuddin Mohammad. Improve software quality thro- ugh practicing devops automation. Sikender Mohsienuddin Moham- mad,”IMPROVE SOFTWARE QUALITY THROUGH PRACTICING DEVOPS AUTOMATION”, International Journal of Creative Research Thoughts (IJCRT), ISSN, pages 2320–2882, 2018.
[34] DevOps Monitoring. Dosegljivo: https://www.atlassian.com/
devops/devops-tools/devops-monitoring, 2021. [Dostopano: 5. 4.
2021].
[35] Understanding Continuous Monitoring in DevOps? Dosegljivo:
https://medium.com/devopscurry/understanding-continuous- monitoring-in-devops-f6695b004e3b, 2021. [Dostopano: 5. 4. 2021].
Diplomska naloga 51 [36] Moving Beyond Traditional App Testing with AI and DevOps. Do- segljivo: https://www.pcloudy.com/moving-beyond-traditional- app-testing-with-ai-and-devops/, 2018. [Dostopano: 21. 6. 2021].
[37] Pearl vi : An epitome on agile modeling(am). Dosegljivo:
https://agilepearls.wordpress.com/tag/active-stakeholder- participation/, 2014. [Dostopano: 9. 11. 2020].
[38] Scrum (skram, gruˇc). Dosegljivo: https://projekt35.si/2020/06/
04/scrum-skram-gruc/, 2020. [Dostopano: 23. 6. 2020].
[39] Scrum (software development). Dosegljivo: https://en.wikipedia.
org/wiki/Scrum_(software_development), 2020. [Dostopano: 4. 6.
2020].
[40] Mali Senapathi, Jim Buchan, and Hady Osman. Devops capabilities, practices, and challenges: Insights from a case study. pages 57–67, 06 2018.
[41] Test automation). Dosegljivo: https://en.wikipedia.org/wiki/
Test_automation, 2020. [Dostopano: 22. 10. 2020].
[42] The guide to building a devops change management plan. Do- segljivo: https://victorops.com/blog/the-guide-to-building-a- devops-change-management-plan, 2019. [Dostopano: 16. 11. 2020].
[43] The Importance of Change Management When Introducing New Soft- ware. Dosegljivo: https://www.unleashedsoftware.com/blog/the- importance-of-change-management-when-introducing-new-
software, 2015. [Dostopano: 23. 6. 2021].
[44] Top 10 practices for effective devops by scott w. ambler.
Dosegljivo: https://blog.telliant.com/top-10-practices-for- effective-devops-by-scott-w-ambler-dr-dobbs-com/, 2013. [Do- stopano: 9. 11. 2020].
[45] Sricharan Vadapalli. DevOps: continuous delivery, integration, and de- ployment with DevOps: dive into the core DevOps strategies. Packt Publishing Ltd, 2018.
[46] Jan Waller, Nils C Ehmke, and Wilhelm Hasselbring. Including perfor- mance benchmarks into continuous integration to enable devops. ACM SIGSOFT Software Engineering Notes, 40(2):1–4, 2015.
[47] What Is Agile Software Development? Dosegljivo: https://www.
outsystems.com/blog/posts/agile-software-development/, 2018.
[Dostopano: 11. 6. 2020].
[48] What Is Automation Testing (Ultimate Guide To Start Test Au- tomation). Dosegljivo: https://www.softwaretestinghelp.com/
automation-testing-tutorial-1/, 2020. [Dostopano: 22. 10. 2020].
[49] What is configuration management? Dosegljivo: https://www.
netapp.com/devops-solutions/configuration-management/what- is-configuration-management/, 2020. [Dostopano: 10. 11. 2020].
[50] What Is Continuous Integration and How to Benefit From It? Dosegljivo: https://nevercode.io/blog/what-is-continuous- integration-and-how-to-benefit-from-it/, 2020. [Dostopano: 9.
10. 2020].
[51] What is DevOps? Dosegljivo: https://aws.amazon.com/devops/
what-is-devops/, 2020. [Dostopano: 4. 9. 2020].
[52] What is DevOps? Dosegljivo: https://www.atlassian.com/devops#
history-of-devops, 2020. [Dostopano: 4. 9. 2020].
[53] What is Extreme Programming? Dosegljivo: https://ronjeffries.
com/xprog/what-is-extreme-programming/, 2011. [Dostopano: 5. 6.
2020].
Diplomska naloga 53 [54] What Is Extreme Programming? An Overview of XP Rules and Values.
Dosegljivo: https://www.lucidchart.com/blog/what-is-extreme- programming, 2020. [Dostopano: 5. 6. 2020].
[55] What Is Test Automation? A Simple, Clear Introduction). Do- segljivo: https://www.testim.io/blog/what-is-test-automation/, 2020. [Dostopano: 22. 10. 2020].
