Skip to main content
Login | Suomeksi | På svenska | In English

Browsing by Author "Blomster, Saila"

Sort by: Order: Results:

  • Blomster, Saila (2019)
    Tutkielman tarkoituksena on arvioida sopimuksen mukaista suoritusta asiakaskohtaisessa ohjelmistohankinnassa. Erilaisia ohjelmistoja käytetään tänä päivänä avustamaan liiketoiminnan päätöksentekoprosessissa. Päätös tietyn toimen toteuttamiseksi voi siten perustua ohjelmiston suorittamien tulosten tulkintaan. Tyypillisesti projektitoimitushankkeisiin lähdetään, kun valmisohjelmisto ei sovellu tilaajan tarpeisiin tai vaihtoehtoisesti tilaaja tavoittelee niin kutsutta kilpailuetua. Useimmissa tilanteissa nämä hankkeet liittyvät kuitenkin yrityksen kriittisiin ydinalueisiin liiketoiminnan harjoittamisen ja jatkuvuuden kannalta. Tavanomaisesti asiakaskohtaisten ohjelmistohankintojen osalta ilmenee ongelmia, kun lopputulos eroaa merkittävästi siitä, mitä alun perin oli sovittu tai kuviteltu sovittavan. Ohjelmistoprojektien perinteisimpi malli tunnetaan nimellä vesiputousmalli. Malli on sopimusoikeudellisesti klassisempi, jolloin lähtökohtana on, että sopimuksen kohde määritellään yksityiskohtaisesti projektiin lähdettäessä eikä tehtyihin määrityksiin enää puututa projektin aikana. Muutosalttiissa ohjelmistokehitysympäristössä tämä ajattelutapa on lähes mahdoton eikä muutoksilta voida välttyä. Ketterillä menetelmillä on pyritty vastaamaan vesiputousmallin haasteisiin. Ketterät menetelmät soveltuvat joustavuutensa puolesta erityisesti sellaisiin ohjelmistoprojekteihin, joissa vaatimuksia ei ole joko tarkoituksenmukaista tai mahdollista määritellä sitovasti etukäteen projektin alussa. Toisaalta selkeän dokumentaation puute voi johtaa siihen tilanteeseen, että sovitut toiminnallisuudet voivat olla epäselviä riitatilanteissa. Ketterissä menetelmissä osapuolten roolit eroavat merkittävästi siitä, mihin vesiputousmallia hyödyntävissä projekteissa on totuttu. Tällä on luonnollisesti vaikutusta osapuolten väliseen riskin- ja vastuunjakoon. Sopimukset ja sopimusehdot voidaan suoritusvelvoitteen osalta jakaa sellaisiin, joissa oikea suoritus on tietyn ennalta sovitun lopputuloksen aikaansaaminen sekä sellaisiin, joiden sisältönä on huolellinen toiminta ilman varsinaista takuuta tietyn ennalta määritellyn lopputuloksen saavuttamisesta. Tutkielmassa havainnollistetaan tulos- ja toimintavelvoitteiden välisiä eroavaisuuksia ohjelmistotoimitusten kontekstissa. Erityisesti ohjelmistotoimituksia koskevissa riita-asioissa tilaaja tyypillisesti katsoo, että toimittajalla on ollut tulosvastuu toimintavalmiista ohjelmistosta, kun taas toimittaja koittaa siirtää vastuutaan enemmän toimintavelvoitteen puolelle, jolloin sopimuksen kohteena on ollut tilaajalta paljon myötävaikutusvelvollisuutta edellyttävä avoin konsultointipohjainen ohjelmistokehitysprojekti. Toiminta- ja tulosvelvoitteen välillä on erityisesti merkitystä projektisopimuksen purkamisen kannalta. Tutkielmassa selvitetään virheen käsitettä ohjelmistojen kontekstissa. Ohjelmistot ovat harvoin täysin virheettömiä. Alan jatkuvan kehityksen vuoksi toimittajat joutuvat lanseeraamaan tuotteensa markkinoille vähäisellä testauksella. Mikäli toimittajat käyttäisivät testaukseen pitkiä aikoja, on riskinä, että tuote voi olla markkinoille päästyään jo vanhentunut teknologian jatkuvan kehittymisen vuoksi. Lisäksi jatkuva virheiden korjaaminen johtaisi kierteeseen, jossa paljastuisi uusia korjausta edellyttäviä virheitä. Alan jatkuvan kehityksen johdosta alan virhetoleranssi on muodostunut selkeästi korkeammaksi muihin aloihin verrattuna. Alalle ei ole kerennyt muodostua vakiintuneita selkeitä standardeja, joihin lopputulosta voitaisiin verrata sen havaitsemiseksi, vastaako projektin lopputulos sovittua. Tämä on erityisen korostunut asiakaskohtaisten ohjelmistojen osalta. Toimittajat sitoutuvat tavanomaisesti vain siihen, että ohjelmisto vastaa olennaisilta osin sitä, mitä määrityksistä on sovittu. Tällöin mielenkiintoinen kysymys onkin, onko vähäisiä virheitä sisältävä ohjelmisto katsottavissa sopimuksen mukaiseksi suoritukseksi. Takuuaika asiakaskohtaisten ohjelmistojen osalta on tyypillisesti kuusi kuukautta toimituksen hyväksymisestä. Lyhyt takuuaika selittyy sillä, että ohjelmistot poikkeavat irtaimesta esineestä huomattavasti ohjelmistojen ollessa aineettomia hyödykkeitä. Virheiden ilmetessä vasta tietyn ajan kuluessa ohjelmistoa käytettäessä, on takuuaikaa ohjelmistotoimituksissa pidettävä enemminkin aikajaksona, jonka kuluessa vaikutuksellisen virheen oletetaan ilmenevän.