4.3 Kehitysputkien ja konttikehityksen suhde virheluokitteluun
4.3.2 Kehitysputken ja konttikehityksen yhteenveto
Kehitysputkella kuvataan tiettyjä kokonaisuuksia tai vaiheita, jolloin termillä itsellään ei ole varsinaista suhdetta virheluokitteluiden hyödyntämiseen. Osaltaan on mahdol-lista kuvata, kuinka esimerkiksi virheluokitteluiden vaiheet toteutetaan tai kuinka
47
nämä vaiheet ovat yhtä kokonaisuutta koko sovellusprosessin tuottamisessa. Itse kehi-tysputkilla ei ole merkitystä virheluokittelussa. Kun kehityskokonaisuutta havainnol-listetaan kehitysputkilla, niin saadaan paremmin ymmärrystä projektista ja sen osi-oista, joissa käytetään virheluokitteluita.
Jotta esimerkiksi putkimainen tai konttikehitys olisi mahdollisimman saumatonta ja sujuvaa, tarvitaan putkissa käsiteltävien entiteettien/objektien suhteiden eli relaatioi-den kuvaamista ja ymmärtämistä. Tätä varten on olemassa erilaisia viitekehyksiä (re-ference frameworks) kuten IT4IT, jossa toimittajariippumattomasti kuvataan eri vai-heet eli suunnittele (plan), toteuta (build), toimita (deliver) ja käytä (run). Kun esimer-kiksi IT4IT-viitekehystä tarkastelee tarkemmin, niin siinä toteuta-vaihe sisältää sovel-lustuotannon elinkaaresta tuttuja vaiheita (Kuva 11).
Kuva 11: IT4IT-viitekehyksen vaiheet ja niiden tarkennuksia (mukaillen The Open Group 2017)
Konttikehityksessä erilaiset poikkeavuudet ja puutteellisuudet pyritään luokittelemaan ja mahdollisesti korjaamaan automaattisesti (Kuva 12). Jotta automaattinen korjaami-nen tai mahdollikorjaami-nen toimeksianto saadaan tehtyä, niin tarvitaan tietoa konfiguraation rakenneosasta (configuration item, CI), joka on määritelty seuraavasti: ”mikä tahansa komponentti tai muu palveluominaisuus, jota täytyy hallita IT-palvelun toimittami-sessa”. Informaatio jokaisesta konfiguraation rakenneosasta (CI) kirjataan konfiguraa-tiotietueena konfiguraationhallintajärjestelmään ja sitä ylläpidetään koko sen elinkaa-ren ajan konfiguraationhallintaprosessilla. CI:t ovat muutoksenhallinnan valvonnassa.
Suunnittele
48
CI:t ovat tyypillisesti IT-palveluja, laitteistoja, ohjelmistoja, rakennuksia, ihmisiä ja virallisia asiakirjoja, kuten prosessidokumentaatio ja palvelutasosopimukset16.
Kuva 12: Luokittelu osana poikkeavuuksien ja puutteellisuuksien käsittelyä (mukaillen Intasoft 2012 ja Immonen 2003)
16 http://itsmf.fi/wp-content/uploads/2014/03/ITIL_2011_Finnish_Glossary_v1.0.pdf
49
5 Johtopäätökset ja pohdinta
Virheistä on olemassa yleisiä määritelmiä, jotka voivat vielä erikseen vaihdella riip-puen organisaatiosta, mutta merkitykset eivät muutu. Virheitä voidaan määritellä ja luokitella muun muassa tyypin ja virhesijainnin mukaisesti, joiden avulla voidaan luoda erilaisia luokitteluita eri tarpeiden mukaisesti. Kuten virheluokitteluissa on kä-sitelty, luokittelua voidaan kohdentaa halutulla tarkkuudella muun muassa muokkaa-malla eri luokkien määrää. Lisäksi on mahdollista muokata useamman tason luokitte-luita, joilla voidaan tarkastella yleiseltä tasolta tarkempiin yksityiskohtiin. Virheistä, virheluokitteluista ja -rakenteista käytettävien määrittelyiden on hyvä olla selkeitä ja ymmärrettäviä. Käytettävissä luokitteluissa kannattaa olla ohjeistusta ja selitettä muun muassa luokkien osista ja käytettävyydestä, jotta saadaan hyvä hyöty luokitteluiden käytöstä.
Elinkaarimalleista on oleellista hahmottaa virheiden tarkastuksen, korjaamisen ja ke-hittäminen toteutuminen käytännössä. Perinteisissä elinkaarimalleissa ohjelmistovir-heiden luokitteluilla on paljon suurempi merkitys, koska niissä käytetään erilaisia tes-taustapoja. Perättäisissä malleissa ei välttämättä tehdä jatkuvaa testausta vaan kaikki suunnitellaan pääosin projektin alussa eli nämä testaus- ja suunnitteluvaiheet keskitty-vät yksittäisiin vaiheisiin periaatteena olla palaamatta aikaisempiin vaiheisiin. Kette-rässä kehityksessä testaus painottuu jatkuvaan testaukseen, joten hyöty virheluokitte-lusta on vähäisempää kuin perinteisissä elinkaarimalleissa.
Erilaisia virheluokittelumenetelmiä on useita. Hyvän luokittelun ominaisuuksia ovat mm. yksiselitteisyys, toistettavuus projektista toiseen samalla tavalla sekä selkeät luo-kat, jotka kaikkiaan helpottavat virheiden luokittelua, oikein toteuttamista ja tiedon-saantia päätöksentekoa varten.
Perusteluina virheluokittelujen käytölle voidaan esittää mm. seuraavia syitä: ensiksi-kin ohjelmistokehitysprosessin - oli kyseessä perinteinen tai moderni kehitysmene-telmä - kehittäminen edellyttää virheiden tunnistamista, luokittelua ja analysointia,
50
jossa selvitetään virheiden syy-seuraussuhteita. Täten virheluokitteluiden avulla voi-daan kehittää kehitysprosessia ja siten ennaltaehkäistä virheitä. Toinen tärkeä syy vir-heidenhallinnan käytölle on testausprosessin hyvä hallinta virheluokitteluiden avulla.
Virheluokittelumenetelmät poikkeavat toisistaan lähinnä luokkien määrän ja sekä nii-den sisältömäärittelyinii-den osalta. Esimerkiksi ketterissä menetelmissä oleellista on vir-heluokkien selkeys ja käytännössä myös luokkien lukumäärän pienuus, jotta virhe-luokituksella ei menetetä ketterän menetelmän tehokkuutta eli pyritään noudattamaan minimaalisuuden periaatetta.
Suurissa kehitysprojekteissa, joihin ketterät menetelmät eivät parhaiten sovellu, voi-daan virheiden luokittelua tarvittaessa toteuttaa tiheämmällä luokittelulla ja myös hyö-dyntää luokittelussa useamman projektin virhedataa. Tällaiseen tilanteeseen soveltuu hyvin monitasoinen virheluokittelumenetelmä, josta hyvänä esimerkkinä voidaan pi-tää SAWO-luokittelukäytäntöä. Myös on mahdollista luoda yrityskohtaisesti itselleen sopivampi oma luokittelukäytäntö perustuen mm. virhedataan tai muihin virheluokit-teluihin mahdollistaen siten yritykselle maksimaalisesti sopivan luokittelukäytännön ja virhedatan hallinnan.
Luvussa kolme on esitelty erilaisia kehittämisessä käytettäviä elinkaarimalleja, joiden osalta merkittävä ero on kommunikaation määrässä organisaation eri ryhmien välillä.
Esimerkiksi vesiputousmallissa yhteistyö asiakkaan kanssa keskittyy projektin alkuun ja projektin loppuun sekä eri hyväksymisvaiheisiin. Sen sijaan agile-mallissa pyrki-myksenä on tehdä tiivistä yhteistyötä koko projektin ajan suunnitteluvaiheesta käyt-töönottovaiheeseen asti. DevOps-mallissa puolestaan pyritään tekemään yhteistyötä kaikkien osapuolien kanssa aina suunnitteluvaiheesta tuotantovaiheeseen saakka.
Nykyisin sovelluskehityksessä käytetään enimmäkseen ketteriä ja moderneja menetel-miä (esim. Agile) ja perinteisen sovelluskehityksen eli vesiputousmallin käyttö vähe-nee koko ajan. Edellä mainittuun kehitykseen voidaan nähdä kaksi perussyytä:
1) Ketterissä menetelmissä asiakas pääsee paremmin vaikuttamaan tavoiteltuun lop-putulokseen kuin perinteisissä malleissa. Asiakas on jatkuvasti tietoinen projektin
51
tilasta koska asiakas on tiiviisti kehittämissyklissä mukana. Lisäksi ketterissä me-netelmissä tavoitteena on tuottaa uusia ominaisuuksia uusien versioiden avulla mahdollisimman nopeasti, mikä motivoi asiakasta sitoutumaan projektiin perin-teistä käytäntöä paremmin.
2) Ketterillä ja moderneilla malleilla pyritään myös parempaan kustannustehokkuu-teen sovellustuotannossa. Tätä asiaa valottaa Auteur Ron Eringa 2017 artikkeli.
Kyseisessä artikkelissa kuvataan, kuinka Agile-projektissa korjataan virheet sa-man tien niitä havaittaessa ja toisaalta vesiputousmallissa virheet löydetään huo-mattavasti myöhemmin ja korjataan testaus ja hyväksymisvaiheessa. Kuten monet tutkimukset ovat osoittaneet, ovat virheen aiheuttamat kustannukset merkittävästi sitä suurempia, mitä myöhemmin ne havaitaan ja päästään korjaamaan. Edellä ole-van perusteella voidaan ketteriä menetelmiä pitää huomattavasti perinteisiä käy-täntöjä kustannustehokkaampana.
Ketterät menetelmät sopivat parhaiten pieniin ja keskisuuriin projekteihin. Käytettä-essä ketteriä menetelmiä suurissa projekteissa voi tulla haasteita projektin hallinnassa.
Näin ollen perinteiset mallit, kuten vesiputousmallit, soveltuvat suurien projektien to-teuttamiseen ja hallintaan. Suurissa projekteissa voisi olla tehokasta käyttää vesipu-tousmallia hallitsemaan kokonaisuutta ja sen sisällä soveltuvin osin tehtäisiin alipro-jekteja ketterällä menetelmällä ja siten myös saadaan ketterien menetelmien etuja.
Virheiden hallintaa tarvitaan niin perinteisessä kuin modernissa sovelluskehityksessä, koska kehitysprosessien edelleen kehittäminen edellyttää virheidenhallintaa (defect management) eli mm. virheiden tunnistamista, luokittelua sekä analysointia, jotta voi-daan tehdä päätöksiä korjaavista ja virheitä ennaltaehkäisevistä toimenpiteistä. Virhe-luokitteluiden osalta ODC eli ortogonaalinen virheluokittelu (Orthogonal Defect Clas-sification) näyttäisi olevan yleisesti käytetty luokittelu, mikä johtunee siitä, että se on IBM:n kehittämä virheluokittelumenetelmä ja lisäksi IBM on kehittänyt sitä tukevia työkaluja käytettäväksi virhedatan hallinnassa. Muiden luokittelujen osalta ei löytynyt tieteellisiä lähteitä niiden käytöstä modernissa ohjelmistotuotannossa johtuen niiden toistaiseksi vähäisestä käytöstä.
52
Virheluokittelua tulee tarkastella sovellustuotannon lisäksi myös IT- ja/tai palveluhal-linnan näkökulmista. Konttien ja konfiguraation rakenneosien kohdentaminen voi edesauttaa yhdenmukaisuutta (conformity) sekä validoinnin ja verifioinnin automati-sointiasteen nostamista.
Moderneissa elinkaarimalleissa, kuten DevOps tavoitteena on toteuttaa testauksen tomatisointia mahdollisimman täydellisesti. Samalla voidaan hyödyntää ketterästi au-tomaatiota virhedatan hallinnassa ja siten on saatavissa jatkuvasti tietoa kehitteillä ole-van sovelluksen tilasta.
53
Lähdeluettelo
Agile Alliance, 2017, Agile 101, WWW-sivusto, https://www.agilealliance.org/agile101/, (03.11.2017)
Agile Finland, 2001, “Agile manifesto/Ketterän ohjelmistokehityksen julistus“, WWW-sivusto, Lassi Koskela, http://agilemanifesto.org/iso/fi/manifesto.html, (03.11.2017)
Ruben Alexandersson, D. Krishna Chaitanya, Peter Öhman, Yasir Siraj, 2005, “A Tech-nique for Fault Tolerance Assessment of COTS Based Systems”, “International Confer-ence on Computer Safety, Reliability, and Security”, SAFECOMP 2005, Springer, 165-178, https://link.springer.com/chapter/10.1007/11563228_13
Brian (Bobby) Baker, 5.4.2017, The 2nd Key to Unlocking a DevOps Culture: The vRad Development Pipeline, WWW-sivusto, vRad Mednax company, https://www.vrad.com/the-2nd-key-to-unlocking-a-devops-culture-the-development-pipeline/
Steffen Bartsch, 17.10.2011, “Practitioners' Perspectives on Security in Agile Develop-ment”, IEEE, Availability, Reliability and Security (ARES), 2011 Sixth International Con-ference, Austria, http://ieeexplore.ieee.org/document/6046004/
Pierre Bourque, Richard E. (Dick) Fairley, 2014, SWEBOK v3.0, Guide to the Software Engineering Body of Knowledge, IEEE, www.swebok.org
Juho Burman, 3.3.2015, ”Ohjelmistovirheiden luokittelu prosessin kehittämisen työka-luna”, Luonnontieteen kandidaatin tutkielma, Itä-Suomen yliopisto
BusinessDictionary, 2017, WWW-sivusto, http://www.businessdictionary.com/
J.W. Cangussu, R.M. Karcich, 2005, “A control approach for agile processes”, Computer Software and Applications Conference, 2005. COMPSAC 2005. 29th Annual Interna-tional, UK, http://ieeexplore.ieee.org/document/1508097/
54
Ram Chillarege, 2013, Using ODC to diagnose an Agile enterprise application develop-ment project, IEEE, 2013 IEEE International Symposium on Software Reliability Engi-neering Workshops (ISSREW) conference, USA, http://ieeexplore.ieee.org/document/6688862/
Narain Chutijirawong, 2013, IBM DevOps “Seize market opportunities by establishing an enterprise capability for continuous software delivery”, IBM Thailand, https://www- 01.ibm.com/events/wwe/grp/grp010.nsf/vLookupPDFs/1.%20IBM%20DevOps%20by%20Narain%20Chutiji-rawong/$file/1.%20IBM%20DevOps%20by%20Narain%20Chutijirawong.pdf
Hasan Çifci, 2004, A Workflow Based Online Software Review System, The Middle East Technical University, The department of information systems, https://etd.lib.metu.edu.tr/up-load/12605078/index.pdf
Domenico Cotroneo, Roberto Pietrantuono, Stefano Russo, 2013, Testing techniques se-lection based on ODC fault types and software metrics, University of Naples, Naples, Italy, Elsevier, Journal of Systems and Software, Volume 86, Issue 6, p. 1613-1637, http://www.sciencedirect.com/science/article/pii/S0164121213000319
Gregory T. Daich, 30.4.2002, “Defining a Software Testing Strategy”, WWW-sivusto, STSC Software Technology Support Center, LinkedIn SlideShare, https://www.slideshare.net/Softwarecentral/defining-a-software-testing-strategy-3744025, (3.11.2017)
Docker, 2016, “Technical Brief Docker Hub Build, Share & Collaborate”, https://goto.docker.com/rs/929-FJL-178/images/docker-hub_0.pdf
Docker, 2016, “Modern Application Architecture for the Enterprise”,
https://www.docker.com/sites/default/files/WP_Modern%20App%20Architecture%20for%20Enterprise%20-%20Jan%202016.pdf
Meghann L. Drury-Grogan, Kieran Conboy, Tom Acton, 22.12.2016, “Examining Deci-sion Characteristics & Challenges for Agile Software Development”, Elsevier, The Jour-nal of Systems & Software, Volume 131, Issue 131, p. 248-265, http://www.sciencedi-rect.com/science/article/pii/S0164121217301103
55
Eficode Oy, 2017, “Devops Eficode opas”, Helsinki, https://www.eficode.com/learn/devops-
opas?ads_cmpid=741247668&ads_adid=37173653925&ads_matchtype=e&ads_net- work=g&ads_creative=177008716221&utm_term=devops&ads_targetid=kwd-
16269965220&utm_campaign=&utm_source=adwords&utm_me-dium=ppc&ttv=2&gclid=CMPvhvfVj9ICFRNlGQodWvsHcg
Khaled El Emam, Isabella Wieczorek, 1998, “The repeatability of code defect classifica-tions”, 1998. Proceedings. The Ninth International Symposium on Software Reliability Engineering, Paderborn, Germany, IEEE, p. 322-333, http://ieeexplore.ieee.org/document/730897/
Auteur Ron Eringa, 26.3.2017, ”Managing Defects in an Agile environment”, Proware-ness+, https://content.demand-on.com/acton/attachment/31254/f-0030/1/-/-/l-0080/l-0080:16c/Whitepa-per%20managing%20defects%20in%20an%20Agile%20environment.pdf
B.S. Farroha, D.L. Farroha, 2014, “A Framework for Managing Mission Needs, Compli-ance, and Trust in the DevOps Environment”, 2014 IEEE Military Communications Con-ference, Baltimore, MD, USA, IEEE, p. 288-293, http://ieeexplore.ieee.org/document/6956773/
Ossian Hartig, 18.1.2012, ”Mikä ihmeen DevOps?”, Tietoviikko-artikkeli, http://www.tivi.fi/Uutiset/2012-01-18/Mik%C3%A4-ihmeen-DevOps-3189340.html
Ville Helminen, 2015, Projektinhallinta ja laadunvarmistus Globaalissa ohjelmistonkehi-tyksessä, Itä-Suomen yliopisto, http://epublications.uef.fi/pub/urn_nbn_fi_uef-20160020/urn_nbn_fi_uef-20160020.pdf
Rashina Hoda, Norsaremah Salleh, John Grundy, Hui Mien Tee, 17.1.2017, “Systematic literature reviews in agile software development: A tertiary study”, Elsevier
Umme Hunny, Mohammad Zulkernine, Komminist Weldemariam, 2013, “OSDC: adapt-ing ODC for developadapt-ing more secure software”, SAC Conference, Symposium on Applied Computing, New York, USA, ACM, p. 1131-1136, https://dl.acm.org/cita-tion.cfm?id=2480574&CFID=1001581841&CFTOKEN=84515482
56
Syed W Hussaini, 2014, “Strengthening harmonization of Development (Dev) and Oper-ations (Ops) silos in IT environment through systems approach”, Intelligent Transporta-tion Systems (ITSC), 2014 IEEE 17th InternaTransporta-tional Conference, IEEE, p. 178-183, , Qing-dao, China, http://ieeexplore.ieee.org/document/6957687/
IEEE, 2010, IEEE Standard Classification for Software Anomalies, IEEE organization, USA, http://ieeexplore.ieee.org/servlet/opac?punumber=5399058
IEEE, 1992, “1992 Index”, IEEE Transactions on Software Engineering, IEEE, Volume 18, Issue 12, p. 1108-1116, https://www.computer.org/csdl/trans/ts/1992/12/e1108-abs.html
Jarkko Immonen, 18.3.2003, Johdatus Ohjelmistotuotantoon -kurssisivusto, WWW-sivu, Joensuun yliopisto, http://cs.joensuu.fi/~jimmonen/jot_moniste/jot_moniste_121.html
Intasoft Ltd, 2012, Out-of-the-box templates, WWW-sivusto, http://www.intasoft.net/in-dex.php/our-products/allchange/, (3.11.2017)
IntroPro, 2017, Expertise Software Delivery Pipeline, WWW-sivusto, https://www.intro-pro.com/expertise/sdlc, (3.11.2017)
ISO, 2017, ISO Online Browsing Platform (OBO) Searching-page, WWW-sivusto, https://www.iso.org/obp/ui#search, (3.11.2017)
ISO, 2015, “ISO 9000:2015(en) Quality management systems — Fundamentals and vo-cabulary”, WWW-sivusto, https://www.iso.org/obp/ui#iso:std:iso:9000:ed-4:v1:en:term, (3.11.2017) ISO, 2014, ” ISO/IEC 25051:2014(en) Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing”, WWW-sivusto, https://www.iso.org/obp/ui#iso:std:iso-iec:25051:ed-2:v1:en:term:4.1.2, (3.11.2017)
ISO, 2013, ” ISO/IEC 15026-1:2013(en) Systems and software engineering — Systems and software assurance — Part 1: Concepts and vocabulary”, WWW-sivusto, https://www.iso.org/obp/ui#iso:std:iso-iec:15026:-1:ed-1:v1:en:term:3.4.4, (3.11.2017)
57
ISO, 2010, ” ISO/IEC/IEEE 24765:2010(en) Systems and software engineering — Vo-cabulary”, WWW-sivusto, https://www.iso.org/obp/ui#iso:std:iso-iec-ieee:24765:ed-1:v1:en:term:3.764, (3.11.2017)
ISO, 2010, ” ISO/IEC/IEEE 24765:2010(en) Systems and software engineering — Vo-cabulary”, WWW-sivusto, https://www.iso.org/obp/ui#iso:std:iso-iec-ieee:24765:ed-1:v1:en:term:3.1027, (3.11.2017)
ISTQB, 2017, “ISTQB Worldwide Software Testing Practices Report 2016-2017”, https://goo.gl/blSLH8
ISTQB Exam Certification, katsottu 15.8.2017, “What is Waterfall model- advantages, disadvantages and when to use it?”, ISTQB Exam Certification -sivusto, http://istqbexamcer-tification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/
ISTQB, 2016 “ISTQB® Worldwide Software Testing Practices Report 2015-2016”, http://www.istqb.org/references/surveys/istqb-worldwide-software-testing-practices-report.html
ISTQB, 2012, ISTQB:n testaussanasto, http://www.fistb.fi/sites/fistb/files/liitteet/istqb_sa-nasto_2015-04-30%202.3%20ENG-FI.pdf
IT Knowledge portal, 2017, Software Development Methodologies, http://www.itinfo.am/eng/software-development-methodologies/, (3.11.2017)
itSMF.fi, 2011, ITIL-sanasto ja lyhenteet Suomenkielinen, http://itsmf.fi/wp-con-tent/uploads/2014/03/ITIL_2011_Finnish_Glossary_v1.0.pdf
Gene Kim, Kevin Behr, Kim Spafford, 2013, “The Phoenix Project: A novel about IT, DevOps, and Helping Your Business Win”, 1st edition. IT Revolution Press, United States of America.
Sami Kollanus, Jussi Koskinen, Survey of software inspection research, University of Jyväskylä, 2009, https://pdfs.semanticscholar.org/8b16/a9b1eb45ffb5bb8fa3cdd52c9e7d679d2cd0.pdf
58
Jarkko Kröger, 4/2017, ”DevOps - työnkulut ja viitekehykset”, Itä-Suomen yliopisto, Tie-tojenkäsittelylaitos, http://urn.fi/urn:nbn:fi:uef-20170383
Sakthi Kumaresh & R. Baskaran, 2010, Defect Analysis and Prevention for Software Pro-cess Quality Improvement, International Journal of Computer Application (0975 -8887) Volume 8 - No.7, Academia.edu, https://www.academia.edu/6984738/Defect_Analysis_and_Preven-tion_for_Software_Process_Quality_Improvement
Eetu Kupiainen, Mika V. Mäntylä, Juha Itkonen, 20.2.2015, "Using metrics in Agile and Lean Software Development - A systematic literature review of industrial studies", Infor-mation and Software Technology, Volume 62, Elsevier, p. 143-163, http://www.sciencedi-rect.com/science/article/pii/S095058491500035X
Mary Lotz, 5.7.2013, “Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?”, WWW-sivusto, Segue Technologies, http://www.seguetech.com/waterfall-vs-agile-methodology/
Zaigham Mahmood, Saqib Saeed, 2013, “Impact of cloud adoption on agile software de-velopment”, Software Engineering Frameworks for the Cloud Computing Paradigm (2013), SpringerLink, p. 213-234, https://link.springer.com/chapter/10.1007/978-1-4471-5031-2_10 Matthias Marschall, 18.5.2010, ” Why Automated Testing is a Must for DevOps”, WWW-sivusto, Agile Web Development & Operations, http://www.agileweboperations.com/why-auto-mated-testing-is-a-must-for-devops
Jan Maximilian, Winther Kristiansen, 2009, “Using Orthogonal Defect Classification In A Norwegian Software Company”, http://www.idi.ntnu.no/grupper/su/fordypningsprosjekt-2009/tdt4520-janmaxim-final-20091216.pdf
Tommi Mikkonen, 2017, “DevOps What Does Science Say?” Helsingin yliopisto, 2017, Devops 2017, Helsinki
59
Eric Minick, 2017, “IBM DevOps Overview & Roadmap An approach for continuous delivery of software driven innovation for our enterprise clients”, IBM, tarkastettu
8.8.2017,
https://www- 01.ibm.com/events/wwe/grp/grp004.nsf/vLookupPDFs/Cloud%20Track_200pm_IBM_DevOps_Over-view/$file/Cloud%20Track_200pm_IBM_DevOps_Overview.pdf
Ernest Mueller, 24.7.2017,” What is Devops”, the agile admin-sivusto, https://theagilead-min.com/what-is-devops/
Pooya Musavi, Bram Adams, Foutse Khomh, 2016, “Experience Report: An Empirical Study of API Failures in OpenStack Cloud Environments”, 2016 IEEE 27th International Symposium on Software Reliability Engineering (ISSRE) conference, IEEE, p. 424-434, http://ieeexplore.ieee.org/document/7774540/
Mika V. Mäntylä, Casper Lassenius, 2009. “What Types of Defects Are Really Discov-ered in Code Reviews?”, IEEE Transactions on Software Engineering, Volume 35, Issue 3, p. 430-448, http://ieeexplore.ieee.org.ezproxy.uef.fi:2048/abstract/document/4604671/?part=1
Naveen, katsottu 15.8.2017, ” What is Waterfall Model in software testing and what are advantages and disadvantages of Waterfall Model”, Testingfreak-sivusto, http://testing-freak.com/waterfall-model-software-testing-advantages-disadvantages-waterfall-model/
Don Opperthauser, 2003, “Defect Management in an Agile Development Environment”,
CROSSTALK, AgileTek,
http://static1.1.sqspcdn.com/static/f/702523/9292638/1289017852037/200309-Opperthauser.pdf?to-ken=JH7O0ATP305utjqBGVfYlnNO3AA%3D
Gerald O’Regan, 2002, “A Practical Approach to Software Quality, Springer Science”, https://books.google.fi/books?id=no7wBwAAQBAJ&printsec=frontcover&hl=fi&source=gbs_ge_sum-mary_r&cad=0#v=onepage&q&f=false
Ost Indie Games, 10.6.2016, Game Development Pipeline, WWW-sivusto, author:
“magicrat_larry”, https://ostindiegames.wordpress.com/2015/06/11/game-development-pipeline/
60
Pulasthi Perera, Madhushi Bandara, Indika Perera, 26.1.2017, ”Evaluating the impact of DevOps practice in Sri Lankan software development organizations”, Advances in ICT for Emerging Regions (ICTer), 2016 Sixteenth International Conference, Sri Lanka, IEEE, p. 281 – 287, http://ieeexplore.ieee.org/document/7829932/
Mike Perrow, 2013, The IBM Rational 2013 IT and EM Spring Launch Story, IBM, http://www.ibm.com/developerworks/rational/library/2013-it-em-spring-launch/index.html?ca=drs-
(2.8.2017)
David B. Peterson, 15.11.2013, Reinventing Executive Coaching to Accelerate Leadership Developlment, IBC Intituto Brasileiro De Coaching, LinkedIn SlideShare, https://www.slideshare.net/IbcCoaching1/reinventing-executive-coaching-to-accelerate-leadership-develop-ment-david-peterson
Monvorath Phongpaibul & Barry Boehm, 2007, A Replicate Empirical Comparison be-tween Pair Development and Software Development with Inspection, University of Cali-fornia, ESEM 2007, Proceedings of the First International Symposium on Empirical Soft-ware Engineering and Measurement, IEEE, p. 265-274, http://ieeexplore.ieee.org/docu-ment/4343754/
Anu Raninen, Tanja Toroi, Hannu Vainio & Jarmo J. Ahonen, 2012, “Defect Data Anal-ysis as Input for Software Process Improvement”, Springer Berlin Heidelberg, Proceed-ings of the 13th International Conference on Product-Focused Software Process Improve-ment, PROFES 2012, O Dieste, A Jedlitschka, N Juristo, https://link.springer.com/chap-ter/10.1007/978-3-642-31063-8_2
Jonathan Rasmusson, katsottu 7.8.2017, “What is Agile”, Agile in nutshell -sivusto, http://www.agilenutshell.com/agile_vs_waterfall
Michael Rowe, (päivitetty 27.9.2013), “DevOps for mobile development”, IBM devel-operWorks, https://www.ibm.com/developerworks/mobile/library/mo-mobile-devops/index.html
Ted Schönbeck, 28.4.2017, “DevOps, microservices and containers - from hype to reality with Red Hat Openshift”, Red Hat Nordics, DevOps 2017, Helsinki
61
Sapan K Shah, 2008, “Cost Benefit Analysis for Software Process Improvements”, Uni-versity of Surrey, United of Kindom, https://core.ac.uk/download/pdf/103062.pdf
Nuno Silva, Marco Vieira, 2016, “Software for Embedded Systems: A Quality Assess-ment based on improved ODC taxonomy”, SAC '16, Proceedings of the 31st Annual ACM Symposium on Applied Computing, USA, ACM, p. 1780-1783, https://dl.acm.org/cita-tion.cfm?id=2851908&CFID=1001581841&CFTOKEN=84515482
Mark Smalley, Dave Van Herpen, 18.6.2014, “Agile! DevOps! What's next? ValOps?
(TFT14 Summer)”, BrightTALK-sivusto, https://www.brighttalk.com/webcast/9795/114767/agile-devops-whats-next-valops-tft14-summer
Mark Smalley, 16.6.2014, “Valops”, LinkedIn Slideshare -sivusto, https://www.slideshare.net/Smalley_IT_Publications/valops
Solinor, katsottu 2.8.2017, “DevOps - Tehostettua ohjelmistokehitystä”, Solinor-sivusto, https://solinor.fi/devops-tehostettua-ohjelmistokehitysta/?gclid=CM6ZhOLVj9ICFUyMGQodXSUGJA
V. Suma, T.R. Nair Gopalakrishnan., 2009, “Defect management strategies in software development”, Intec Web Publishers, Vienna, Austria, https://arxiv.org/abs/1209.5573
Sunsup So, Yongseop Lim, Sung Deok Cha & Yong Rae Kwon, 1995, “An Empirical
Sunsup So, Yongseop Lim, Sung Deok Cha & Yong Rae Kwon, 1995, “An Empirical