MIKKO AHO KONFIGURAATIONHALLINTA AUTOMAATIOJÄRJESTELMÄ- PROJEKTEISSA Diplomityö

Koko: px
Aloita esitys sivulta:

Download "MIKKO AHO KONFIGURAATIONHALLINTA AUTOMAATIOJÄRJESTELMÄ- PROJEKTEISSA Diplomityö"

Transkriptio

1 MIKKO AHO KONFIGURAATIONHALLINTA AUTOMAATIOJÄRJESTELMÄ- PROJEKTEISSA Diplomityö Tarkastaja: Professori Hannu Koivisto Tarkastaja ja aihe hyväksytty tiedekuntaneuvoston kokouksessa

2 II TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Automaatiotekniikan koulutusohjelma AHO, MIKKO: Konfiguraationhallinta automaatiojärjestelmäprojekteissa Diplomityö: 79 sivua, 15 liitesivua Huhtikuu 2009 Pääaine: Oppivat järjestelmät Työn tarkastaja: Professori Hannu Koivisto Avainsanat: konfiguraationhallinta, projektinhallinta, automaatiojärjestelmän kehitys Tämän diplomityön tavoitteena oli lisätä Säteilyturvakeskuksen (STUK) tietämystä konfiguraationhallintaan liittyen erityisesti automaatiojärjestelmäprojekteissa. Konfiguraationhallinta pitää sisällään kaikki toiminnot, jotka liittyvät tuotteen konfiguraation muutosten hallintaan. Konfiguraatiolla tarkoitetaan jonkin asian ominaisuuksien tai sisällön muodostamaa kokonaisuutta ja, etenkin ohjelmistotuotteita ja asiakirjoja käsiteltäessä, eri versioita. Konfiguraationhallinnassa tuotteet järjestetään pienempiin kokonaisuuksiin, joissa niiden koko elinkaaren aikaisia vaiheita hallitaan samalla säilyttäen kokonaisuuden eheyden. Konfiguraationhallinta on yksi projektin tukitoimista, joka on mukana projektin jokaisessa elinkaaren vaiheessa. Epäonnistunut konfiguraationhallinta voi vaikuttaa negatiivisesti kaikkiin projektille asetettuihin tärkeimpiin tavoitteisiin kuten tuloksen laatuun, turvallisuuteen, aikatauluun ja hintaan. Konfiguraatioyksikkö ja perustaso ovat tärkeimmät konfiguraationhallinnassa käytettävät termit. Konfiguraatioyksiköllä tarkoitetaan mitä tahansa puolivalmista tai valmista tuotetta, jota käsitellään konfiguraationhallinnan järjestelmässä yhtenä kokonaisuutena. Perustaso on taas sellainen tuotteen kehitysvaihe, jossa konfiguraatioyksikkö todistetusti toteuttaa sille määritellyt ominaisuudet. Perustason tarkoituksena on olla etenemispiste, joka voidaan mitata, perusta myöhemmälle kehittämiselle ja kontrollille sekä mittauspiste laadun ja tarkoituksenmukaisuuden arvioimiselle ennen kuin lopullinen järjestelmä on julkaistu. Konfiguraationhallinnassa on tekniikkaa enemmän kysymys johtamisesta ja suuremman kuvan hahmottamisesta. Kokonaiskuvan hahmottamisessa avainasemassa ovat projektiin osallistuvien organisaatioiden organisaatiokulttuurit ja organisaatioiden yhteistoiminta. Myös toimitusketjun rakenteella ja toimintojen synkronoimisella eri osapuolten välillä on vaikutuksia konfiguraationhallintaan. Tässä työssä tehtyjen asiantuntijahaastattelujen mukaan konfiguraationhallintaan liittyviin asioihin tulisi yleisesti kiinnittää projekteissa enemmän huomiota. Erityisesti kaikille projektin osapuolille yhtenäinen ja yksityiskohtainen konfiguraationhallinnan ohjeistus olisi välttämättömyys jokaisessa laajemmassa projektissa. Diplomityössä laadittiin Säteilyturvakeskukselle koottua ohjeistusta konfiguraationhallinnan suunnitelman ja sen noudattamisen tarkastamisen tueksi. Konfiguraationhallinnan suunnitelmassa määritellään miten konfiguraationhallinta toteutetaan tietylle projektille. Konfiguraationhallinnan suunnitelma sisältää useimpien standardien mukaan seuraavat informaatioluokat: johdanto, johto, toiminnot, aikataulut, resurssit ja suunnitelman ylläpito.

3 III ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Master s Degree Programme in Automation Science and Engineering AHO, MIKKO: Configuration Management in Automation System Projects Master of Science Thesis: 79 pages, 15 Appendix pages April 2009 Major: Intelligent Systems Examiner: Professor Hannu Koivisto Keywords: configuration management, project management, development of automation system The aim of this Master s thesis was to increase knowledge about configuration management, especially in automation system projects, at the Nuclear Safety Authority Finland (STUK). Configuration management includes all operations that involve management of changes in configuration of an item. Configuration itself refers to an aggregation that consists of some matter s attributes or content and, especially when discussing about software products or documents, different versions. In configuration management (CM), items are organized into smaller units where their life cycle phases are managed while maintaining integrity of the entity. Configuration management is one of the project support processes that are enclosed in all life cycle phases of the project. Unsuccessful configuration management can affect negatively on all the project s most important objectives, e.g., quality, safety, schedule and cost. Configuration item and baseline are the most important terms in CM. A configuration item is any semi-finished or finished item that represents one entity and is under configuration change control. A baseline is a stage of development where a configuration item demonstrable fulfils attributes that are specified to it. A baseline is intended to be a measurable progress point, a basis for subsequent development and control and a measurement point for assessing quality and fitness for purpose, before the final system is released. Configuration management is more a case of management and piecing together a bigger picture than technology. When piecing together a bigger picture, organization cultures and cooperation of project organizations are in a key position. Also, structures of operational networks and synchronisation of operations between different project parties have impacts on CM. According to interviews of specialists done in this work, organizations should pay more attention to CM in projects in general. Especially CM regulation that is detailed and uniform between all project parties would be a necessity in all projects. A collection of directions was created in this Master s thesis work to support STUK s work when it examines configuration management plans and their observance. A configuration management plan is a document defining how configuration management will be implemented for a particular acquisition or program. A configuration management plan has, according to most of the standards, classes of information as follows: Introduction, Management, Activities, Schedules, Resources and Plan Maintenance.

4 IV ALKUSANAT Tämä diplomityö on tehty Säteilyturvakeskuksella ydinvoimalaitosten valvontaosastolla sähkö- ja automaatiojärjestelmät-toimistossa. Olen hyvin kiitollinen Säteilyturvakeskukselle heidän osoittamasta luottamuksesta ja mahdollisuudesta tehdä diplomityöni heidän palveluksessaan. Erityisesti haluan kiittää työn ohjaajaa Mika Koskelaa, joka työkiireiden ja elämän haasteiden keskellä jaksoi ja ehti ohjata minua työssäni eteenpäin. Kiitän myös työn tarkastajaa professori Hannu Koivistoa arvokkaista ohjeista, ja tässä työssä haastattelemiani Säteilyturvakeskuksen asiantuntijoita positiivisesta suhtautumisesta haastattelujani kohtaan. Haluan kiittää lisäksi kaikkia läheisiäni, jotka ovat olleet omalta osaltaan tukemassa opiskeluani ja muistuttamassa elämän tärkeimmistä arvoista. Varsinkin elämän suurempien asioiden päätepisteet laittavat pysähtymään hetkeksi ja muistelemaan miten tähän on päädytty. Matkan varrelle on mahtunut paljon vaikeita ja hyviä hetkiä sekä opetuksia, joita ei voinut sisällyttää tähän työhön. Elämässä saa opetuksia jatkuvasti ja paljon enemmän on varmasti vielä oppimatta. Tämä työ on kuitenkin päätös tähänastiselle opiskelulleni sen viimeinen osa. Helsingissä 23. syyskuuta 2009 Mikko Aho

5 V SISÄLLYS TIIVISTELMÄ...II ABSTRACT... III ALKUSANAT...IV SISÄLLYS... V TERMIEN MÄÄRITELMÄT... VII 1. JOHDANTO PERUSTEET MONIMUTKAISUUS JA SEN HALLINTA AUTOMAATIOJÄRJESTELMÄKOKONAISUUKSISSA KONFIGURAATIONHALLINNAN MÄÄRITELMÄ JA PERUSKÄSITTEET Konfiguraatioyksikkö Perustaso Konfiguraationhallinnan suunnitelma Tuotteen konfiguraation informaatio Konfiguraationhallinnan perustoiminnot LYHYT HISTORIA OHJELMISTOJEN KONFIGURAATIONHALLINTA KONFIGURAATIONHALLINTAAN KÄYTETTÄVÄT OHJELMISTOTYÖKALUT KONFIGURAATIONHALLINNAN TUOMIA HYÖTYJÄ MAHDOLLISIA ONGELMIA, JOS KONFIGURAATIONHALLINTAA EI KÄYTETÄ Jaetun tiedon ongelma Moninkertaisen ylläpidon ongelma Samanaikaisen kehityksen ongelma Muita ongelmia IHMINEN KONFIGURAATIONHALLINNAN SUURIMPANA HAASTEENA PROJEKTIT JA KONFIGURAATIONHALLINTA PROJEKTIN MÄÄRITELMÄ JA SIDOSRYHMÄT PROJEKTIN ELINKAARIMALLIT AUTOMAATIOJÄRJESTELMÄN ELINKAARIMALLI Turvallisuuteen liittyvät järjestelmät Ydinvoimalan automaatiojärjestelmähankintaprojektin vaiheet SYSTEEMIN ELINKAAREN PROJEKTIPROSESSIT KONFIGURAATIONHALLINNAN TOTEUTUKSEN VAIHEET JÄRJESTELMÄN TOIMITUSPROJEKTISSA STANDARDIT JA OHJEET YLEISTÄ STANDARDEISTA KONFIGURAATIONHALLINNAN STANDARDIT JA OHJEET ANSI/EIA-649-A ANSI/EIA-836A: IEEE Std ISO-10007: MIL-STD MIL-HDBK-61A(SE) PROJEKTIORGANISAATIOIDEN TOIMINTATAVAT JA KONFIGURAATIONHALLINTA KONFIGURAATIONHALLINNAN TOIMINNAN JÄRJESTÄMINEN ORGANISAATION SISÄLLÄ Konfiguraationhallinnan tiimin organisointi Konfiguraationhallinnan lautakunnan organisointi TOIMINTAKULTTUURIEN PUUTTEET JA HAASTEET... 46

6 VI Osaaminen Kommunikointi Resurssien oikea kohdistaminen Sitoutuminen Koulutus TOIMITUSKETJUN RAKENNE JA SEN VAIKUTUKSIA KONFIGURAATIONHALLINTAAN Vertikaalinen integraatio Toimitusverkoston rakenteen muuttaminen KONFIGURAATIONHALLINNAN SYNKRONOINTI PROJEKTIN OSAPUOLTEN VÄLILLÄ ASIANTUNTIJAHAASTATTELUT KONFIGURAATIONHALLINNAN SUUNNITELMA KONFIGURAATION TUNNISTAMINEN MUUTOKSENHALLINTA TILATIEDON HALLINTA JA KONFIGURAATIONHALLINTAAN KÄYTETTÄVÄT TYÖKALUT KONFIGURAATIONHALLINTAAN LIITTYVÄT AUDITOINNIT JA KATSELMUKSET RAJAPINTOJEN HALLINTA RESURSSIT JA AIKATAULUT ALIHANKKIJOIDEN JA TOIMITTAJIEN HALLINTA OLKILUOTO 3-PROJEKTISTA SAATUJA KOKEMUKSIA KONFIGURAATIONHALLINTAAN LIITTYEN KONFIGURAATIONHALLINNAN SUUNNITELMAN OHJEELLINEN SISÄLTÖ TAUSTAA JOHDANTO KONFIGURAATIONHALLINNAN JOHTAMINEN KONFIGURAATIONHALLINNAN TOIMINNOT Konfiguraation tunnistaminen Konfiguraation muutoksenhallinta Konfiguraation tilatiedon hallinta Konfiguraation katselmukset ja auditoinnit Rajapintojen hallinta Alihankkijoiden ja toimittajien hallinta Tuotanto Prosessien hallinta Tiimityöskentely KONFIGURAATIONHALLINNAN AIKATAULUT KONFIGURAATIONHALLINNAN RESURSSIT KONFIGURAATIONHALLINNAN SUUNNITELMAN YLLÄPITO JOHTOPÄÄTÖKSET LÄHTEET LIITTEET... 80

7 VII TERMIEN MÄÄRITELMÄT auditointi (audit) järjestelmällinen, riippumaton ja dokumentoitu prosessi, jossa hankittavaa auditointinäyttöä arvioidaan objektiivisesti sen määrittämiseksi, missä määrin sovitut auditointikriteerit on täytetty (SFS-EN ISO 9000:2005) auditointikriteerit (audit criteria) kokoelma menettelyjä tai vaatimuksia (SFS-EN ISO 9000:2005) auditointinäyttö (audit evidence) tallenteet, tositteet tai muu informaatio, joka liittyy auditointikriteereihin ja joiden olemassaolo voidaan todentaa (SFS-EN ISO 9000:2005) elinkaari (life cycle) tuotteen peräkkäiset tai vuorovaikutteiset vaiheet raaka-aineiden hankinnasta tai tuottamisesta luonnonvaroista loppukäsittelyyn ja sijoitukseen (SFS-EN ISO 14040:2006) Elinkaari on se ajanjakso, joka alkaa, kun järjestelmä- tai laitetarve määritellään ja päättyy, kun kyseessä oleva järjestelmä romutetaan tai mahdollisesti siirtyy toiseen käyttöön. (Kosola 2007) infrastruktuuri (infrastructure) organisaation toimintaa varten tarvittavien tilojen, laitteiden ja palveluiden järjestelmä (SFS-EN ISO 9000:2005) katselmus (review) toiminto, joka suoritetaan asetettujen tavoitteiden saavuttamiseksi tarvittavien toimenpiteiden sopivuuden, asianmukaisuuden, tehokkuuden ja vaikuttavuuden määrittämiseksi (SFS-EN ISO 9000:2005) Katselmuksia ovat esimerkiksi johdon katselmus, suunnittelun ja kehityksen katselmus, asiakkaan vaatimusten katselmus ja poikkeavuuden katselmus. (SFS-EN ISO 9000:2005) koeteltu teknologia (proven technology) koeteltu teknologia sisältää seuraavat ominaisuudet (Laaksonen 2002): asianmukaisesti arvioidut käyttökokemukset uusien teknologioiden kokeelliset näytöt ja analyysit

8 VIII konfiguraatio (configuration) 1. olemassa olevan tai suunnitteilla olevan tuotteen tai tuotteiden yhdistelmän ominaisuuksien/piirteiden muodostama kokonaisuus 2. yksi järjestystä noudattavaa kehitystapaa käyttäen luodun tuotteen variaatioista (muokattu lähteestä: ANSI/EIA-649-A 2004) konfiguraation auditointi (configuration audit) ennen konfiguraatioyksikön vahvistamista/luovutusta pidetty katselmus, jossa varmistetaan, että auditoitava konfiguraatioyksikkö todella vastaa asetettuja vaatimuksia ja että konfiguraatioyksikkö on asianmukaisesti testattu ja dokumentoitu (ISO 10007:2003) konfiguraation dokumentaatio (configuration documentation) tekninen dokumentti, jonka ensisijaisena tehtävänä on määritellä ja esittää tuotteen suorituskykyä sekä toiminnallisia ja fyysisiä ominaisuuksia (MIL-HDBK-61A(SE) 2001) konfiguraationhallinta (configuration management) prosessi, jonka tarkoituksena on luoda ja pitää yllä tuotteen ominaisuuksien yhtenäisyyttä sen vaatimusten ja tuotteen konfiguraation informaation kanssa tuotteen elinkaaren ajan (ANSI/EIA-649-A 2004) konfiguraationhallinnan lautakunta (configuration control board, CCB) lautakunta, joka koostuu sekä teknisistä että hallinnollisista edustajista, jotka suosittelevat hyväksymistä tai hylkäystä ehdotettuihin muutoksiin ja poikkeamiin, jotka kohdistuvat tuotteen nykyiseen hyväksyttyyn dokumentaatioon (MIL-HDBK-61A(SE) 2001) konfiguraationhallinnan suunnitelma (configuration management plan) dokumentti, joka määrittelee miten konfiguraationhallinta implementoidaan, sisältäen menettelytavat ja prosessit, tietylle projektille (MIL-HDBK-61A(SE) 2001) konfiguraation tilatiedon raportti (configuration status accounting report) raportti, joka kuvaa pyydetyt tallennetut tiedot, kuten esimerkiksi konfiguraatioyksiköiden ja perustasojen versiohistorian konfiguraatioyksikkö (configuration item, CI) mikä tahansa puolivalmis tai valmis tuote, joka toteuttaa käyttötarkoituksensa ja on määritelty erilliseen konfiguraationhallintajärjestelmään ja jota kohdellaan yksittäisenä kokonaisuutena konfiguraationhallinnassa (ISO 10007:2003) laatu (quality) se, missä määrin luontaiset ominaisuudet täyttävät vaatimukset (SFS-EN ISO 9000:2005)

9 IX lievennetty tuote (waiver, deviation) tuote, joka ei täytä vaatimuksia, mutta joka hyväksytään toimitettavaksi eteenpäin siitä huolimatta (MIL-STD-973) luovutus, julkaisu (release) lupa edetä prosessin seuraavaan vaiheeseen (SFS-EN ISO 9000:2005) määritelmä, jolla nimitetään tapahtumaa, jossa konfiguraatioyksiköksi sopiva tuote on valmis jaettavaksi, hyväksytty sopivan määräysvaltaisen tahon (engl. authority) toimesta ja on konfiguraation muutoksenhallintaprosessien kohteena (MIL-HDBK-61A(SE) 2001) muutos (change) muunnelma olemassa olevaan konfiguraatioyksikköön asianmukaisen tahon hyväksymisen jälkeen, mikä johtaa uuteen konfiguraatioyksikön versioon (Schaap et al. 2007) konfiguraation muutoksella tarkoitetaan muutosta tuotteessa ja/tai tuotteen konfiguraation informaatiossa (ANSI/EIA-649-A 2004) perustaso (baseline) hyväksytty informaatio, joka tunnistaa ja todentaa tuotteen ominaisuudet johonkin tiettyyn ajanhetkeen ja palvelee muutosten määrittelyn perustana (ANSI/EIA-649-A 2004) konfiguraatioyksikön kehityksen vaihe, jossa konfiguraatioyksikkö todistetusti toteuttaa sille määritellyt ominaisuudet ja jota voidaan muuttaa vain määritellyn prosessin kautta poikkeama (nonconformance, nonconformity) vaatimuksen täyttymättä jääminen (SFS-EN ISO 9000:2005) prosessi (process) sarja toisiinsa liittyviä tai vuorovaikutteisia toimintoja, jotka muuttavat syötteet tuotoksiksi (SFS-EN ISO 9000:2005) rajapinta (interface) fyysinen, toiminnallinen tai suorituskykyyn liittyvä vuorovaikutus kahden tai useamman konfiguraatioyksikön välillä (MIL-STD-973) rajapintojen hallinta (interface control) prosessi, joka tunnistaa, dokumentoi ja hallitsee kaikkia suorituskykyyn liittyviä toiminnallisia ja fyysisiä ominaisuuksia, jotka ovat merkityksellisiä kahden tai useamman konfiguraatioyksikön yhdistämiseksi (MIL-STD-973)

10 X revisio, tarkennettu versio (revision) seuraus tuotteen tai tuotteen konfiguraation informaation päivittämisestä (ANSI/EIA-649-A 2004) systeemi, järjestelmä (system) toisiinsa liittyvien tai vuorovaikutteisten tekijöiden yhdistelmä (SFS-EN ISO 9000:2005) tuote (item) prosessin tulos (SFS-EN ISO 9000:2005) Yleisiä tuoteluokkia on neljä: palvelut (esim. kuljetus), tietotuotteet (esim. tietokoneohjelmat, dokumentit), tavaratuotteet (esim. generaattori), prosessoidut materiaalit (esim. voiteluaineet). (SFS-EN ISO 9000:2005) tuotteen konfiguraation informaatio (product configuration information) määrittelee vaatimukset tuotteen suunnittelulle, valmistukselle, verifioinnille, käytölle ja tuelle (ISO 10007:2003) vaatimus (requirement) tarve tai odotus, joka on erityisesti mainittu, yleisesti edellytetty tai pakollinen (SFS-EN ISO 9000:2005) validointi, kelpuutus, kelpoistaminen (validation) objektiiviseen näyttöön perustuva varmistuminen siitä, että tiettyä käyttöä tai soveltamista koskevat vaatimukset on täytetty (SFS-EN ISO 9000:2005) verifiointi, todentaminen (verification) objektiiviseen näyttöön perustuva varmistuminen siitä, että määritellyt vaatimukset on täytetty (SFS-EN ISO 9000:2005) versio (version) yksi useasta, peräkkäisesti luodusta, tuotteen konfiguraatiosta (ANSI/EIA-649-A 2004) (vertaa revisio)

11 11 1. JOHDANTO Ohjelmistopohjaista automaatiojärjestelmää kehitettäessä lopputuotteen ominaisuuksiin vaikuttavat tekijät voidaan jakaa suoriin ja välillisiin tekijöihin. Suorat tekijät muodostuvat pääasiassa varsinaisista suunnittelu- ja valmistusvirheistä, kun taas välilliset tekijät vaikuttavat suorien tekijöiden esiintymistiheyteen ja siten tätä kautta lopputuotteen tärkeimpiin ominaisuuksiin kuten laatuun, luotettavuuteen ja turvallisuuteen. Kaikkien välittömien virheiden havainnointi vaatisi lopputuotteen täydellisen tarkastamisen. Reaalimaailman yhä monimutkaistuvissa järjestelmissä ja järjestelmäkokonaisuuksissa tämä ei ole mahdollista, ja esimerkiksi ohjelmistopohjaisten automaatiojärjestelmien hyväksyntätarkasteluissa nojataan yhä enenemässä määrin välilliseen näyttöön, kuten esimerkiksi suunnitteluprosessin laatuun. Konfiguraationhallinta prosesseineen on yksi keskeisistä välillisistä tekijöistä ohjelmistopohjaisen automaatiojärjestelmän tärkeimpiä ominaisuuksia ajatellen. Diplomityö koskee tätä aihetta keskittyen konfiguraationhallinnan yläkäsitteeseen, ja erityisesti siihen, miten konfiguraationhallintaa tulisi soveltaa automaatiojärjestelmäprojekteissa. Työn tavoitteena on käsitellä tyypillisen automaatiojärjestelmäprojektin konfiguraationhallintaa kokonaisuutena siten, että tunnistetaan esimerkiksi: - konfiguraationhallinnan yleiset ominaispiirteet - konfiguraationhallinnan liittymäpinnat projektinhallintaan ja siihen liittyviin perusprosesseihin - automaatiojärjestelmäprojektiin liittyvät eri osapuolet (esimerkiksi toimittaja, tilaaja, viranomainen) ja näiden vaikutus konfiguraationhallintaprosesseihin. Diplomityön kirjallisuusosuudessa käydään läpi kirjallisuudessa hyväksytyt perusperiaatteet ja parhaat käytännöt käyttäen taustamateriaalina standardeja, viranomaisohjeita ja muuta alaan liittyvää kirjallisuutta. Diplomityö keskittyy pääosin turvallisuuskriittiseen automaatioon, mutta tulokset ovat sovellettavissa myös käyttöautomaatioon. Diplomityön tutkimuksellisen osuuden tavoitteena on luoda ohje, jota Säteilyturvakeskus voi käyttää arvioidessaan konfiguraationhallinnan suunnitelmien sisältöä, niiden noudattamista ja konfiguraationhallintaan liittyviä riskejä ja käytäntöjä. Ohje kootaan asiantuntijahaastatteluiden sekä alan standardien ja kirjallisuuden pohjalta. Tämän lisäksi luodaan lista indikaatioista/indikaattoreista, jotka ilmentävät huonosta konfiguraationhallinnasta aiheutuvaa luotettavuus/turvallisuusriskiä.

12 12 2. PERUSTEET Tässä luvussa taustoitetaan automaatiojärjestelmien monimutkaisuuksista muodostuvaa ongelmakenttää, kerrotaan konfiguraationhallinnan tärkeimmistä käsitteistä ja esitellään konfiguraationhallinnan perustoiminnot lyhyesti. Luvussa käydään myös läpi konfiguraationhallinnan historiaa, kerrotaan ohjelmistojen konfiguraationhallinnasta ja konfiguraationhallinnassa käytettävistä ohjelmistotyökaluista. Tämän lisäksi esitellään konfiguraationhallinnan käytön mukanaan tuomia hyötyjä ja haasteita sekä muutamia ongelmia, joita organisaatio voi kohdata jos konfiguraationhallintaa ei käytetä asianmukaisella tavalla. 2.1 Monimutkaisuus ja sen hallinta automaatiojärjestelmäkokonaisuuksissa Perinteisten prosessien ohjauksen lisäksi automaatiojärjestelmät hoitavat nykyisin ylemmän tason toimintoja ja tietämyksen hallintaa. Automaatiojärjestelmä voi ulottua antureista ja toimilaitteista johtajan pöydälle, joissakin tapauksissa jopa kotiin (Kuva 1; Kuva 2). Sovellusten laajeneminen ja monimutkaistuminen tuovat haasteita automaatiosuunnittelijoille ja muille niiden kanssa työskenteleville. Kuva 1: Automaatiojärjestelmän tasot (ANSI/ISA95, Koiviston 2006 mukaan)

13 13 Kuva 2: Automaatiojärjestelmän tasot, yleisesti hyväksytty malli (ANSI/ISA95, Koiviston 2006 mukaan) Ohjelmistotekniikan merkitys on sekin kasvamassa, sillä automaatio laajenee tietojärjestelmien puolelle ja prosessien ohjauksessa sovelletaan yleisesti tietoteknisiä sovelluksia, jotka sisältävät esimerkiksi optimointia ja vaativaa signaalien käsittelyä (Ajo et al. 2001). Myös järjestelmien väliset rajapinnat voivat olla laajoja, sillä järjestelmien välillä halutaan vaihtaa tietoja monella tasolla. Integroinneissa on otettava huomioon mekaanisen, sähköisen ja ohjelmallisen yhteensopivuuden lisäksi looginen ja toimintaprosessien yhteensopivuus. (Asmala et al. 2005) PC-pohjaisen teknologian ja ohjelmistokomponenttien käyttöön liittyviä hyötyjä ja ongelmia on käsitelty Taulukossa 1. Taulukko 1: PC-pohjaisen teknologian ja ohjelmistokomponenttien käyttöön liittyviä hyötyjä ja ongelmia (Pietilä 2004) Kohta Hyötyjä Ongelmia Hinta ja tarjonnan laajuus: laiteteknologia on suhteellisen edullista ja automaation ohjelmistokomponentteja tekevän teollisuuden kasvu monipuolistaa tarjontaa ja laskee myös ohjelmistojen hintoja. Teknologia on tuttua jo yrityksen toimintaympäristöstä ja sen käyttö mahdollistaa automaation eri tasojen integroinnin ja informaation kulun periaatteessa alimmalta kenttäväylätasolta internetiin. Yksittäisten komponenttien oikeanlaisen toiminnan varmistaminen ja erityisesti komponenttien oikea ja haluttu yhteentoimivuus kokonaissovelluksessa. Komponenttien huollon ja päivityksen järjestäminen asianmukaisesti sovelluksia laajennettaessa tai päivitettäessä komponenttien alustoja.

14 14 3. Sovellussuunnittelun hoitaminen kokonaisuutena, sillä suunnittelussa on mukana eri toimijoita ja suunnittelu hoidetaan hajautetusti erilaisilla työkaluilla. 4. Vastuukysymykset vikatilanteissa. Automaatiossa ei pelkästään langoiteta toimilohkoja, vaan sovellus on kokoelma hajautettuja olioita. Uutta ohjelmakoodia tarvitaan vähemmän, kun sovellus kootaan eri valmistajien valmiskomponenteista. Yksittäisen tuotteen voi valmistaa yhteistyössä moni yritys, joiden eri tiimit voivat olla sijoittuneena eri puolilla maailmaa. Tällöin asiakkaan ja kokonaistoimittajan roolit kasvavat, sillä jonkun on vastattava osien laadusta ja yhteensopivuudesta sekä kokonaisuuden toimivuudesta (Ajo et al. 2001). Myös sidosryhmien välinen kommunikointi ja yhteistyö ovat muuttuneet yhä tärkeämmiksi. Järjestelmien verkottuminen ja monimutkaistuminen tekevät kehittämisohjelmien ja hankkeiden koordinoinnista välttämättömyyden, kun koordinointi on aiemmin nähty tarpeelliseksi lähinnä resurssien tehokkaan käytön varmistamiseksi (Kosola 2007). Useilla aloilla, kuten ydinvoimateollisuudessa, myös viranomaisilla on omia vaatimuksia automaatiojärjestelmien toiminnalle ja laadulle. Projektit automaatiojärjestelmien parissa ovat jatkuvasti lisääntyvien ja monimutkaistuvien haasteiden edessä. Yhä monimutkaisemmat hankkeet ovat muutenkin toiminnan ja muutoksen keskiössä. Monet organisaatiot etsivät keinoja toimintansa monimutkaisuuden hallintaan, ja yksinkertaistaminen on suosittu keino, jolla tätä koko ajan lisääntyvää monimutkaisuutta pyritään hallitsemaan. Asioita ei voi kuitenkaan yksinkertaistaa oikealla tavalla ymmärtämättä ensin kokonaisuutta ensin on ymmärrettävä kulloisessakin tapauksessa vallitsevan monimutkaisuuden keskeiset piirteet (Hollming 2008). Tämän vuoksi ei ole olemassa sellaista universaalia toimintamallia, joka toimisi jokaisessa tapauksessa, vaan paras ratkaisu lienee se, että hyväksi havaittuja toimintamalleja muutetaan kulloiseenkin tapaukseen erikseen. Myös konfiguraationhallinta on tietyllä tavalla yksinkertaistamista. Siinä asiat järjestetään pienempiin kokonaisuuksiin, joissa niitä seurataan ja hallitaan ja joita ihmisten on helpompi käsitellä ja hahmottaa. 2.2 Konfiguraationhallinnan määritelmä ja peruskäsitteet Konfiguraatiolla tarkoitetaan tuotteen toiminnallisten ja fyysisten ominaisuuksien muodostamaa kokonaisuutta. Kun esimerkiksi jokin osa tuotteessa vaihtuu tai muuttuu, muuttuu myös tuotteen konfiguraatio. Konfiguraatiolla tarkoitetaan myös, eteenkin ohjelmistotuotteita ja dokumentteja käsiteltäessä, tuotteen tai dokumentin eri versioita. Konfiguraationhallinta pitää sisällään kaikki toiminnot, jotka liittyvät tuotteen konfiguraation muutosten hallintaan. Konfiguraationhallinta on vierasperäinen käännös englanninkielisestä käsitteestä configuration management. Konfiguraationhallinta

15 15 suomennetaan usein termeillä tuotetiedon hallinta tai tuotteenhallinta, mutta konfiguraationhallinnalla tarkoitetaan kuitenkin eri asiaa kuin edellä mainituilla termeillä. Konfiguraationhallinnalle ei ole yhtä yksiselitteistä määritelmää, vaan sille on sekä standardeissa esitettyjä että asiantuntijoiden omia määritelmiä. Käsitteiden määrittelyissä ovat mukana ihmisten ja organisaatioiden näkökulmat, jotka muovautuvat esimerkiksi henkilökohtaisten perusperiaatteiden ja tarkoitusperien mukaan. Yksi ytimekkäimmistä määritelmistä kuuluu seuraavasti: Konfiguraationhallinta on menettelytapa monimutkaisten systeemien kehityksen hallitsemiseksi. (Tichy 2008). Standardissa AN- SI/EIA-649-A 2004 määritellään konfiguraationhallinnan seuraavasti: Konfiguraationhallinta on prosessi, jonka tarkoituksena on luoda ja pitää yllä tuotteen ominaisuuksien yhtenäisyyttä sen vaatimusten ja tuotteen konfiguraation informaation kanssa tuotteen elinkaaren ajan. Buckle (1982) esittää myös melko laajan ja kuvaavan määritelmän: Konfiguraationhallinta on kokoelma tekniikoita, jotka on suunniteltu parantamaan tuotteen laatua tarjoten suuremman läpinäkyvyyden, näytöt kehityksen ja tuotannon etenemisestä ja paremman teknisten asioiden ja johdon hallinnan Konfiguraatioyksikkö Systeemi jaetaan konfiguraationhallinnassa yksittäin tunnistettaviin osiin perusideana se, että pienempiä osia voidaan hallita paremmin. Näitä osia kutsutaan konfiguraationhallinnassa englanniksi termillä configuration item, josta käytetään usein lyhennettä CI. Tässä työssä tämän termin suomennoksena käytetään konfiguraatioyksikköä. Konfiguraatioyksikköjä käytetään siksi, että varsinkin ohjelmistojen kanssa työskennellessä systeemeissä ei ole olemassa luonnollisia mitattavia kokonaisuuksia, joita voitaisiin käyttää mitattaessa edistymistä tai laatua alkuperäisen suunnitelman ja lopullisen tuotteen välillä. Vaikka lopullisen systeemin olemassaolo voidaan osoittaa objektiivisesti, niin sen laatu, ja se, miten se täyttää alun perin suunnitellut vaatimukset, ovat vaikeita osoittaa. (Buckle 1982) Konfiguraatioyksikön lisäksi usein käytettyjä suomennoksia tälle termille ovat hallinta-alkio, kontrolloitu tuote ja yksinkertaisesti sitä voidaan kutsua myös vain tuotteeksi. Kun käytetään termiä tuote, täytyy muistaa, että konfiguraatioyksikkö ja tuote, jota ei seurata konfiguraationhallintajärjestelmässä, omaavat käsitteellisen eron. Esimerkiksi standardissa ANSI/EIA-649-A 2004 konfiguraatioyksikköä ja tuotetta ei ole kuitenkaan määritelty erikseen, vaan termiä tuote käytetään riippumatta siitä seurataanko tuotetta konfiguraationhallinnan avulla vai ei. Termien sekava käyttö voi aiheuttaa väärinkäsityksiä myös alan kirjallisuuteen tutustuessa. Konfiguraatioyksikkö voi olla mikä tahansa puolivalmis tai valmis tuote, joka toteuttaa käyttötarkoituksensa ja on määritelty erilliseen konfiguraationhallintajärjestelmään. Konfiguraatioyksiköitä ovat esimerkiksi lähdekoodi, jonkin moottorin öljynsuodatin, tietokanta, ydinvoimalaitoksen generaattori, testisuunnitelma tai spesifikaatiodokumentti eli tarkka tuotteen ominaisuuksien määritelmä. Konfiguraatioyksiköt voivat olla myös

16 16 tukitoiminnoissa käytettäviä elementtejä kuten esimerkiksi käyttöjärjestelmiä ja ohjelmointityökaluja (IEEE Std ). Vielä laajemman näkemyksen perusteella konfiguraatioyksikön ei tarvitse olla fyysinen kokonaisuus, vaan myös esimerkiksi jokin palvelu voi olla konfiguraatioyksikkö. Kun tarkastellaan jotain suurempaa kokonaisuutta, konfiguraatioyksiköiden valitseminen kannattanee aloittaa systeemin ylätasolta. Eli esimerkiksi kokonainen ydinvoimala voisi olla yksi konfiguraatioyksikkö. Tämä suurin konfiguraatioyksikkö jaetaan tämän jälkeen pienempiin osiin, niin pitkälle kuin se nähdään tarkoituksenmukaisena projektin kaikkien osapuolien kannalta katsottuna. Kaikkia tuotteita ei kuitenkaan valita konfiguraatioyksiköiksi, vaan osa luokitellaan vähemmän tärkeiksi, eikä niitä seurata konfiguraationhallinnassa. Esimerkiksi ydinvoimalarakennuksessa käytettävää jokaista ruuvia ja mutteria ei kannata seurata konfiguraationhallinnan avulla. Konfiguraatioyksiköiksi kannattaa valita esimerkiksi sellaisia tuotteita, jotka ovat kriittisiä systeemin toiminnan tai turvallisuuden kannalta. Konfiguraatioyksikön olisi myös hyvä edustaa erillistä kokonaisuutta, joka suorittaa vähintään yhtä toimintoa. Tuote, joka sisältää komponentin, joka on erilainen vain yhdelle tuotteelle muuten samanlaisten tuotteiden joukossa, olisi myös hyvä valita konfiguraatioyksiköksi. (MIL-HDBK-61A(SE) 2001) Konfiguraatioyksiköiden suuri määrä hankaloittaa konfiguraationhallintaa. Useimmat kehityksen ja tukitoimien virstanpylväät liittyvät konfiguraatioyksiköihin, ja kaikki toiminnot, kuten esimerkiksi testaukset ja auditoinnit, tehdään yleensä jokaiselle valitulle konfiguraatioyksikölle. Konfiguraatioyksiköiden suuri määrä lisää tällöin työn määrää ja aikataulussa pysymiselle tulee haasteita. Suuri valittujen kontrolloitujen tuotteiden määrä lisää myös dokumenttien sirpaloitumista. Tällöin esimerkiksi vaatimuksia, toiminnallisuuksien kuvauksia ja muita dokumentteja saattaa tulla niin paljon, että niitä on vaikea hallita. Konfiguraatioyksiköitä voi tietysti myös olla liian vähän, jolloin konfiguraatioyksiköiden monimutkaisuus kasvaa. Tällöin hallinnollinen näkemys konfiguraatioyksiköihin ja niiden kehityksen arvioiminen vaikeutuvat. Esimerkiksi monimutkaisten konfiguraatioyksiköiden testaus ja uudelleen tilaus hankaloituvat. Mitään tyhjentäviä sääntöjä sille, kuinka monta konfiguraatioyksikköä kullekin systeemille tulisi valita, ei ole olemassa. Yleisesti ottaen on kuitenkin sitä parempi mitä vähemmän konfiguraatioyksiköitä on, kunhan systeemiä pystytään hallitsemaan riittävän hyvin (MIL-HDBK-61A(SE) 2001). Konfiguraatioyksiköiden valitsemisen järjestelmällisyyden lisäämiseksi voidaan laatia omia tai käyttää suuntaviivana jo olemassa olevia ohjeita ja tarkistuslistoja. Luvussa Konfiguraationhallinnan toiminnot esitetään yksi esimerkki tarkastuslistasta, jota voidaan käyttää apuna konfiguraatioyksiköitä valittaessa.

17 Perustaso Englanninkielinen käsite baseline esiintyy lähes aina samassa yhteydessä puhuttaessa konfiguraationhallinnasta. Tässä työssä tästä termistä käytetään suomennosta perustaso. Perustasoksi kutsutaan yleensä sitä konfiguraatioyksikön kehityksen vaihetta, jossa konfiguraatioyksikkö todistetusti toteuttaa sille määritellyt ominaisuudet, on asianmukaisen tahon hyväksymä (esim. asiakkaan tai hallinnon) ja jota voidaan muuttaa vain määritellyn prosessin kautta. Muutoksen syy voi olla esimerkiksi virhe tai tietyn piirteen puuttuminen. (MIL-HDBK-61A(SE) 2001) Perustason käsitteen kanssa on syytä olla tarkkana, sillä se voidaan usein ymmärtää toisin kuin tässä työssä esitetyllä tavalla. Perustasolla voidaan esimerkiksi tarkoittaa pelkästään lopputuotetta ja sen ominaisuuksia (Jonassen Hass 2003). Myös eri organisaatiot ja henkilöt voivat käyttää tätä termiä tarkoittaen eri asiaa. Buckle (1982) määrittelee perustason sen tehtävien kautta. Hänen mukaansa perustaso on tuotteen elinkaaren eri vaiheissa oleva referenssipiste, jonka ominaisuudet voidaan hyväksyttävästi demonstroida. Perustasolla on Bucklen (1982) mukaan kolme toisiinsa liittyvää tarkoitusta: se on etenemispiste, joka voidaan mitata, perusta myöhemmälle kehittämiselle ja kontrollille sekä mittauspiste laadun ja tarkoituksenmukaisuuden arvioimiselle, ennen kuin lopullinen systeemi on julkaistu. Jotta edellä esitetyt perustason tehtävät voidaan saavuttaa, jokaisen perustason pitää osoittaa projektin merkittäviä vaiheita ensimmäisen lausunnon ja toimitettavan tuotteen väliltä. Täten systeemin perustasoja voivat olla esimerkiksi (Buckle 1982) systeemin vaatimusmäärittely (dokumentti), ohjelmiston tarkka määrittely (dokumentti), yksityiskohtainen ohjelmiston suunnitelma (dokumentti), systeemin alustava versio (beta versio) (varsinainen systeemi), systeemin ensimmäinen release candidate (varsinainen systeemi) toinen release candidate (varsinainen systeemi), ja niin edelleen. Usein perustason ja virstanpylvään ajatellaan olevan sama asia, mutta vaikka perustaso on asetettu usein juuri virstanpylväiden kohdalle, sen ei tarvitse aina välttämättä olla tässä kohdassa (Buckle 1982). Perustasot pitää hyväksyttää erikseen, toisin kuin virstanpylväät, ja ne muodostavat formaalin jäädytetyn perustan myöhempää kehitysvaihetta varten. Perustasojen formaalisuuden aste voi myös vaihdella joissakin tapauksissa. Perustaso voi olla hyvin yksinkertainen ja organisaation sisäisen hallinnan alla tai se voi olla hyvin yksityiskohtainen, monimutkainen ja ulkopuolisen tahon valvonnassa. Perustason säädösten alittamiseksi voidaan myös joissakin tapauksissa antaa poikkeuslupa sitä tar-

18 18 vittaessa, jolloin tuotetta kutsutaan lievennetyksi tuotteeksi (engl. deviation, waiver). (MIL-STD-973) Konfiguraationhallinnan suunnitelma Konfiguraationhallinnan suunnitelma on dokumentti, joka määrittelee miten konfiguraationhallinta implementoidaan (sisältäen menettelytavat ja prosessit) tietylle hankinnalle tai ohjelmalle (MIL-HDBK-61A(SE) 2001). Konfiguraationhallinnan suunnitelma tarjoaa raamit ja joukon ohjeita konfiguraationhallinnan asianmukaiseen suorittamiseen. Konfiguraationhallinnan suunnitelmasta on vastuussa yleensä konfiguraationhallinnan tiimin projektipäällikkö. Konfiguraationhallinnan tiimin muodostamisesta ja toiminnasta kerrotaan enemmän tämän työn luvussa 5.1 Konfiguraationhallinnan toiminnan järjestäminen organisaation sisällä. Konfiguraationhallinnan suunnitelma voi olla yksi erillinen dokumentti, osa jotain toista dokumenttia tai se voi olla usean dokumentin yhdistelmä. Joissakin tapauksissa, jos se nähdään tarpeellisena, toimittajaorganisaatio voi myös pyytää alihankkijoita ja tavarantoimittajia laatimaan konfiguraationhallinnan suunnitelman, joka voi olla erillinen tai toimittajaorganisaation suunnitelmaan liitettävä dokumentti. (ISO 10007:2003) Konfiguraationhallinnan suunnitelman asianmukaisuuden varmistamiseksi, varsinkin laajoissa ja merkittävissä projekteissa, tulisi se mielestäni hyväksyä jonkin asianmukaisen ulkopuolisen tahon toimesta ja sen noudattamista sekä siihen tehtäviä muutoksia tulisi myös valvoa Tuotteen konfiguraation informaatio Tuotteen konfiguraation informaatio määrittelee vaatimukset tuotteen suunnittelulle, valmistukselle, verifioinnille, käytölle ja tuelle (ISO 10007:2003). Tuotteen konfiguraation informaatio voidaan jakaa tuotteen määrittelyn informaatioon ja tuotteen käytön informaatioon (Kuva 3). Tuotteen määrittelyn informaatio tarjoaa teknisen perustan, jota tarvitaan tuotteen kaikissa elinkaaren vaiheissa. Se kuvaa tuotteen suorituskyvyn, toiminnalliset ja fyysiset ominaisuudet ja tuotteelle asetetut vaatimukset ja suunnitteluinformaation. Tuotteen käytön informaatio sisältää toimintatavat ja tarvittavan teknisen informaation, jota tarvitaan tuotetta asennettaessa, käytettäessä, ylläpidettäessä ja poistettaessa käytöstä. (ANSI/EIA-649-A 2004)

19 19 Kuva 3. Tuotteen konfiguraation informaatio (ANSI/EIA-649-A 2004) Konfiguraationhallinnan perustoiminnot Tässä vaiheessa käydään läpi konfiguraationhallinnan perustoiminnot vain esitellen niiden sisältöä. Työn myöhemmässä vaiheessa perehdytään tarkemmin konfiguraationhallinnan suunnitelman sisältöön ja samalla yksityiskohtaisemmin konfiguraationhallinnan toimintoihin. Konfiguraation tunnistaminen (engl. configuration identification) on ensimmäinen konfiguraationhallinnan toiminto. Tässä prosessissa määritetään konfiguraatioyksiköt ja perustasot. Aivan ensimmäiseksi systeemi jaetaan konfiguraatioyksiköiksi. Tämän jälkeen kehitetään konfiguraatioyksiköiden tunnistusjärjestelmä. Jokaisesta konfiguraatioyksiköstä tehdään lisäksi dokumentaatio, jossa kuvataan konfiguraatioyksikön ominaisuudet. Muutoksenhallinta (engl. configuration control) on prosessi, jossa arvioidaan, koordinoidaan ja päätetään tietyn muutoksen käyttöönotto konfiguraatioyksiköissä ja perustasoissa, joihin muutos kohdistuu. Tähän prosessiin kuuluu myös hyväksyttyjen muutosten käyttöönotto konfiguraatioyksiköissä ja perustasoissa. Tilatiedon hallintaa (engl. configuration status accounting) käytetään konfiguraatioyksiköihin ja perustasoihin tehtyjen muutosten jäljittämiseen. Tämä prosessi mahdollistaa ja varmistaa sen, että tilatiedot on tallennettu järjestelmään, niitä voidaan tarkkailla ja niiden perusteella voidaan tehdä raportteja. Konfiguraationhallinnan katselmukset ja auditoinnit (engl. configuration verifications and audits) on prosessi, jonka tarkoituksena on varmistaa, että käytetyt prosessit toimivat tarkoituksenmukaisella tavalla. Edellä mainittujen konfiguraationhallinnan perustoimintojen lisäksi konfiguraationhallintaan voidaan ajatella liittyvän muitakin toimintoja, jotka kuvataan myös konfigu-

20 20 raationhallinnan suunnitelmassa. Näitä muita konfiguraationhallinnan toimintoja voivat olla esimerkiksi rajapintojen hallinta, alihankkijoiden ja toimittajien hallinta, tuotanto, prosessien hallinta ja tiimityöskentely. (IEEE Std ; Dart 1991) 2.3 Lyhyt historia USA:n puolustusteollisuus käytti konfiguraationhallintaa ensimmäisen kerran teknisten asiakirjojen hallintaan 1960-luvulla, jolloin myös luotiin ensimmäiset konfiguraationhallinnan standardit (Leon 2005). Suuret tietokoneiden valmistajat ja erikoistuneet ohjelmistotiimit, jotka työskentelivät laajojen projektien parissa erityisesti avaruus- ja puolustusteollisuudessa, käyttivät konfiguraationhallinnan menetelmiä ohjelmistojen kehityksen hallinnan apuna, kun tietokoneet ja ohjelmistot kehittyivät 1970-luvun lopulla ja 1980-luvun alussa (Buckle 1982; Estublier 2000). Konfiguraationhallinnan luonne oli aluksi erilainen, kuin mitä se on nykyisin, koska projektit pysyivät pienemmän piirin sisällä, eikä tarkalle asioiden dokumentoinnille ollut niin suurta tarvetta. Tiedot pysyivät tiimin sisällä helpommin hallinnassa. Nykyisin projektit ovat usein enemmän hajautettuja ja projekteihin liittyy yhä useampia yrityksiä. Konfiguraationhallintaa käytetään nykyisin avaruus- ja puolustusteollisuuden lisäksi muun muassa ydinvoima-, autonvalmistus- ja lääketeollisuudessa. Konfiguraationhallinta on erityisen käyttökelpoinen menettelytapa myös tietoliikenneteollisuudessa alaan liittyvän nopean muutoksen vuoksi. Tiukkojen prosessivaatimusten vuoksi avaruusteknologian projekteissa käytettävää konfiguraationhallintaa voidaan pitää tällä hetkellä korkeimmalla kehityksen tasolla. 2.4 Ohjelmistojen konfiguraationhallinta Ohjelmistojen konfiguraationhallinnalle on omia standardeja ja määritelmiä. Standardi IEEE 1042 määrittelee ohjelmistojen konfiguraationhallinnan seuraavasti: Ohjelmiston konfiguraationhallinta on opinala tietokoneohjelmien evoluution hallinnan johtamiseksi kehityksen ensimmäisistä vaiheista kaikkiin ylläpidon vaiheisiin asti. On yleisen epäselvyyden aihe, mitä eroa perinteisen- ja ohjelmistoihin käytettävän konfiguraationhallinnan välillä oikeastaan on. Pääpiirteissään ohjelmistojen- ja perinteinen konfiguraationhallinta ovat rakennettu samalta pohjalta, mutta ohjelmistojen konfiguraationhallinnassa termistö liittyy pelkästään ohjelmistotuotantoon, kun taas perinteinen konfiguraationhallinta toimii hyvin yleiseltä pohjalta välttäen ottamasta kantaa siihen, mikä tarkasteltava kohde on. Toisena erona voidaan pitää sitä, että ohjelmistoja on paljon helpompi muutella kuin fyysistä tuotetta, ja tähän asiaan kiinnitetään ohjelmistojen konfiguraationhallinnassa yleisesti ottaen enemmän huomiota. Kolmantena erona voidaan nähdä se, että ohjelmistojen konfiguraationhallintaa voidaan automatisoida myös laajalti, koska komponentit ovat tietokoneen hallinnassa. (Ubhi H. et al. 2003)

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia OAMK / Luova 4.5. ja 11.5. Sisäinen auditointi osa Oamkin ympäristöohjelmatyötä Sisältö 1. päivä Johdanto Auditoinnin tavoitteet Ympäristöstandardin (ISO 14001) pääkohdat Alustava ympäristökatselmus Auditoinnin

Lisätiedot

Ohjelmistotuotteen hallinnasta

Ohjelmistotuotteen hallinnasta Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista

Lisätiedot

ISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ

ISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ ISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ IMS Business Solutions Oy, J Moisio 10/ 2016 2.10.2016 IMS Business Solutions Oy 2 ISO 9001:2015 PROSESSIEN AUDITOINTIKYSYMYKSIÄ ISO 9001:2015

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa Sisältö 1. Koneenrakentajan haasteita koneiden turvallistamisessa 2.

Lisätiedot

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi

Lisätiedot

Software engineering

Software engineering Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmäraportti - Konfiguraationhallinta Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology

Lisätiedot

SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY

SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY Anna-Liisa Koskinen SISÄLTÖ Uusi rakenne Uusia määritelmiä Keskeisistä muutoksista 2 ISO 14001 ympäristöjohtamisjärjestelmä ISO 14001 on tunnettu

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

Riippumattomat arviointilaitokset

Riippumattomat arviointilaitokset Riippumattomat arviointilaitokset CSM Riskienhallinta -asetuksen mukainen riippumaton arviointi Komission asetus (352/2009/EY) yhteisestä turvallisuusmenetelmästä, CSM riskienhallinta-asetus, vaatii rautatiejärjestelmässä

Lisätiedot

Projektin suunnittelu

Projektin suunnittelu Projektin suunnittelu Sami Kollanus TJTA330 Ohjelmistotuotanto 15.3. Projektin suunnittelu - CMMIkäytänteet Projektin estimaatit: Määritellään projektin laajuus (scope) Määritellään tehtävien ja tuotosten

Lisätiedot

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt. Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.fi Avoimen tuotteenhallinta Esityksen sisältö Mitä on tuotteenhallinta?

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

LAADUNVALVONTAJÄRJESTELMÄ- JA TOIMEKSIANTOLOMAKE

LAADUNVALVONTAJÄRJESTELMÄ- JA TOIMEKSIANTOLOMAKE LAADUNVALVONTAJÄRJESTELMÄ- JA TOIMEKSIANTOLOMAKE Pyydämme palauttamaan täytetyn lomakkeen osoitteeseen laatu@chamber.fi. Tarkastettava tilintarkastaja Laaduntarkastaja Laadunvalvontajärjestelmän kartoitus

Lisätiedot

Mylab Projektitoiminnan kehittäminen. PM Club Tampere

Mylab Projektitoiminnan kehittäminen. PM Club Tampere Mylab Projektitoiminnan kehittäminen PM Club Tampere 23.11.2016 Sisältö 1. Mylab terveydenhuollon sektorilla 2. Projektitoiminnan kehittäminen ja yleisiä huomioita toimialan projektitoiminnasta 3. Toimitusprojektin

Lisätiedot

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

Lisätiedot

RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS

RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS Loppuseminaari 11.12.2018 YIT:n pääkonttori, Helsinki RAIN hankkeen loppuseminaari 11.12.2018 Käyttäjälähtöinen tiedonhallinta (WP 4) Professori Harri Haapasalo OY

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Opinnäytetyö KESKI-POHJANMAAN AMMATTIKORKEAKOULU Puutekniikan koulutusohjelma Toukokuu 2009 TIIVISTELMÄ OPINNÄYTETYÖSTÄ Yksikkö Aika Ylivieska

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011 AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä

Lisätiedot

Julkaisun laji Opinnäytetyö. Sivumäärä 43

Julkaisun laji Opinnäytetyö. Sivumäärä 43 OPINNÄYTETYÖN KUVAILULEHTI Tekijä(t) SUKUNIMI, Etunimi ISOVIITA, Ilari LEHTONEN, Joni PELTOKANGAS, Johanna Työn nimi Julkaisun laji Opinnäytetyö Sivumäärä 43 Luottamuksellisuus ( ) saakka Päivämäärä 12.08.2010

Lisätiedot

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3 Tuotekonfigurointi ADE Oy lyhyesti Asiakkaiden tarpeisiin suunnattua innovatiivista ja toimivaa ohjelmisto- ja 3d animaatiopalvelua. Ade Oy on toteuttanut vuodesta 2000 alkaen haastavaa interaktiivista

Lisätiedot

Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu?

Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu? Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu? Laatupäällikkö Anna-Maija Haapala osastonylilääkäri, dosentti Fimlab Laboratoriot Oy STANDARDI 15189 (2012) Suomennos standardista

Lisätiedot

SFS-ISO/IEC Tietoturvallisuuden hallintajärjestelmät. Ohjeistusta. Riku Nykänen

SFS-ISO/IEC Tietoturvallisuuden hallintajärjestelmät. Ohjeistusta. Riku Nykänen SFS-ISO/IEC 27003 Tietoturvallisuuden hallintajärjestelmät. Ohjeistusta Riku Nykänen 14.12.2018 SFS-ISO/ IEC 2 70 0 3 Tietoturvallisuuden hallintajärjestelmät. Ohjeistusta Riku Ny kän en, 14.12.2 0 18

Lisätiedot

Ohjelmistojen virheistä

Ohjelmistojen virheistä Ohjelmistojen virheistä Muutama sana ohjelmistojen virheistä mistä niitä syntyy? Matti Vuori, www.mattivuori.net 2013-09-02 1(8) Sisällysluettelo Ohjelmistojen virheitä: varautumattomuus ongelmiin 3 Ohjelmistojen

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Arviointi ja mittaaminen

Arviointi ja mittaaminen Arviointi ja mittaaminen Laatuvastaavien koulutus 5.6.2007 pirjo.halonen@adm.jyu.fi 014 260 1180 050 428 5315 Arviointi itsearviointia sisäisiä auditointeja ulkoisia auditointeja johdon katselmusta vertaisarviointeja

Lisätiedot

Standardi IEC Ohjelmisto

Standardi IEC Ohjelmisto Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Sisältö Mistä tietoja koottu? Opit Yhteenveto Mistä tietoja koottu? Nämä tiedot on kerätty

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä

Lisätiedot

ITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan

ITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan ITSM Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan Olli Saranen Senior Consultant Avoset Oy 31.8.2016 Esittely Mukana suomalaisten pankkijärjestelmien kehittämisessä ja ylläpitotyössä

Lisätiedot

SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor 2014

SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor 2014 SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor Mannerheimintie 2 00100, Helsinki Finland tel: +358 9 4152 0200 www.reaktor.fi info@reaktor.fi 2014

Lisätiedot

Riski = epävarmuuden vaikutus tavoitteisiin. Valtionhallinnossa = epävarmuuden vaikutus lakisääteisten tehtävien suorittamiseen ja tavoitteisiin

Riski = epävarmuuden vaikutus tavoitteisiin. Valtionhallinnossa = epävarmuuden vaikutus lakisääteisten tehtävien suorittamiseen ja tavoitteisiin Juha Pietarinen Riski = epävarmuuden vaikutus tavoitteisiin Valtionhallinnossa = epävarmuuden vaikutus lakisääteisten tehtävien suorittamiseen ja tavoitteisiin - Voiko riski olla mahdollisuus myös lakisääteisten

Lisätiedot

Takki. Lisää ot sik k o osoit t am alla. Nyt se sopii, tai sitten ei. Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi 2010. 3.

Takki. Lisää ot sik k o osoit t am alla. Nyt se sopii, tai sitten ei. Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi 2010. 3. Takki Nyt se sopii, tai sitten ei Jussi Vänskä Espotel Oy vierailuluentosarja OTM kurssi 2010 3. luento: tuote Lisää ot sik k o osoit t am alla Jussi Vänskä OTM kevät 2010 Tuote Mitä tuote voi olla? Tuote

Lisätiedot

Ohjelmistojen suunnittelu

Ohjelmistojen suunnittelu Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136

Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136 Laatudokumentoinnin kehittäminen, sähködokumentaatio-mapin sisältö. 3D-mallinnus ja sen käyttö Lehtori, DI Yrjö Muilu, Centria AMK Ydinosaajat Suurhankkeiden osaamisverkosto Pohjois-Suomessa S20136 Laadunhallintaan

Lisätiedot

Miksi auditoidaan? Pirkko Puranen FT, Ylitarkastaja

Miksi auditoidaan? Pirkko Puranen FT, Ylitarkastaja Miksi auditoidaan? Pirkko Puranen FT, Ylitarkastaja Vaatimus kudoslaitoksille: Fimean määräys 3/2014 Liite V 6. Laatukatselmus 6.1 Toiminnoille, joille lupaa haetaan, on oltava käytössä auditointijärjestelmä.

Lisätiedot

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka

Lisätiedot

Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä

Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä Tuotanto, konseptit, oppiminen yritystoiminnan kehittämisen uudet näkökulmat 25.5.2011 Aalto-yliopiston

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa

Lisätiedot

Software product lines

Software product lines Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product

Lisätiedot

Tulevaisuuden päätelaitteet

Tulevaisuuden päätelaitteet Tulevaisuuden päätelaitteet Kuka ne omistaa? Miten niitä hallitaan? Aki Antman Sulava Oy 2.11.2011 Agenda Alkusanat ja puhujan lyhyt esittely Erilaiset päätteet ja sähköinen työpöytä Kuka omistaa päätelaitteet?

Lisätiedot

Avoimen lähdekoodin kehitysmallit

Avoimen lähdekoodin kehitysmallit Avoimen lähdekoodin kehitysmallit Arto Teräs Avoimen lähdekoodin ohjelmistot teknisessä laskennassa -työpaja CSC, 25.5.2009 Avoimen lähdekoodin kehitysmallit / Arto Teräs 2009-05-25

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

SMS ja vaatimustenmukaisuuden

SMS ja vaatimustenmukaisuuden SMS ja vaatimustenmukaisuuden valvonta Tiedotustilaisuus: Pienet hyväksytyt koulutusorganisaatiot non-complex ATO Vastuullinen liikenne. Yhteinen asia. Turvallisuuden hallintajärjestelmä, SMS ICAO Document

Lisätiedot

Julkisen ja yksityisen sektorin kumppanuus innovatiivisten palveluiden mahdollistajana

Julkisen ja yksityisen sektorin kumppanuus innovatiivisten palveluiden mahdollistajana Julkisen ja yksityisen sektorin kumppanuus innovatiivisten palveluiden mahdollistajana Helsingin Yrittäjien seminaari 1.3.2011 Kumppanuus Yritysmyönteistä yhteistyötä mikko.martikainen@tem.fi Mikko Martikainen

Lisätiedot

Soft QA. Vaatimusten muutostenhallinta. Ongelma

Soft QA. Vaatimusten muutostenhallinta. Ongelma Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei

Lisätiedot

itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance

itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance Markus Leinonen M.Sc. (Econ.), CIA, CISA Senior Manager, Internal Controls Cargotec Oyj 1984 1986 1992 1995 1997 1997 2002 2002 2008

Lisätiedot

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA

Lisätiedot

Potilasturvallisuuden johtaminen ja auditointi

Potilasturvallisuuden johtaminen ja auditointi 1 Potilasturvallisuuden johtaminen ja auditointi Pirjo Berg, Anna Maksimainen & Olli Tolkki 16.11.2010 Potilasturvallisuuden johtaminen ja auditointi Taustaa STM velvoittaa sairaanhoitopiirit laatimaan

Lisätiedot

SOVELLUSALUEEN KUVAUS

SOVELLUSALUEEN KUVAUS Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu SOVELLUSALUEEN KUVAUS LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 2.1 Tila: hyväksytty Päivämäärä: 12.12.2000

Lisätiedot

Projektin suunnittelu. Pienryhmäopetus - 71A00300

Projektin suunnittelu. Pienryhmäopetus - 71A00300 Projektin suunnittelu Pienryhmäopetus - 71A00300 Projektikanvaasi Mikä on projektikanvaasi? Visuaalinen työkalu projektitiimille, joka helpottaa projektin suunnittelussa ja projektin tavoitteiden kommunikaatiossa

Lisätiedot

Auditointi. Teemupekka Virtanen 14.5.2010

Auditointi. Teemupekka Virtanen 14.5.2010 Auditointi Teemupekka Virtanen 14.5.2010 Lähtökohta Kaikki KANTAan liittyneet organisaatiot jakavat saman tietomassan Keskinäinen luottamus Yhteiset toimintaperiaatteet Yhteinen turvataso Minä uskallan

Lisätiedot

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina - Käytännön esimerkkejä ITIL ja ITSM mukaisista IT palveluhallinnan toteutuksista ja mahdollisuuksista Ville Koskinen Sales Specialist, HP Software

Lisätiedot

Periaatteet standardien SFS-EN ISO/IEC 17025:2005 ja SFS-EN ISO 15189:2007 mukaisen näytteenottotoiminnan arvioimiseksi

Periaatteet standardien SFS-EN ISO/IEC 17025:2005 ja SFS-EN ISO 15189:2007 mukaisen näytteenottotoiminnan arvioimiseksi Periaatteet standardien SFS-EN ISO/IEC 17025:2005 ja SFS-EN ISO 15189:2007 mukaisen näytteenottotoiminnan arvioimiseksi FINAS - akkreditointipalvelu Espoo 2012 ISBN 978-952-5610-85-7 1(7) Periaatteet standardien

Lisätiedot

EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen

EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008 Meeri Nieminen Asiakkaan vaihtoehdot Asiakkaan vaihtoehdot EMCS-järjestelmän käyttöön XML-sanomarajapinta oman järjestelmän

Lisätiedot

Harjoitustyö Case - HelpDesk

Harjoitustyö Case - HelpDesk Harjoitustyö Case - HelpDesk Harjoitustyön Case: HelpDesk -sovellus Tietotekniikkatoimittaja AB ja asiakas X ovat viime vuonna sopineet mikrotukiyksikön ulkoistamisesta X:ltä AB:n liikkeenjohdon vastuulle.

Lisätiedot

Laatu tietojärjestelmähankkeissa. Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia

Laatu tietojärjestelmähankkeissa. Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia Laatu tietojärjestelmähankkeissa Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia 5.10.2010 Pohdintaa tietojärjestelmien laadusta Mitä on laatu Miten laatua tavoitellaan tietojärjestelmäprojekteissa

Lisätiedot

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004 Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa 4. Roolimallipalvelu 4.1 Tiedot palvelusta Palvelun nimi: Palvelun versio 01.01.00 Toteuttaa palvelun yksilöllistä palvelua (kts. M14.4.42) Roolimallipalvelu (Model role service) MYJ:lle, jotka toteuttavat

Lisätiedot

PS-vaiheen edistymisraportti Kuopio

PS-vaiheen edistymisraportti Kuopio PS-vaiheen edistymisraportti Kuopio Kuopio, PS-vaiheen edistymisraportti, 30.10.2001 Versiohistoria: Versio Pvm Laatija Muutokset 1.0 30.10.2001 Ossi Jokinen Kuopio2001, vain kurssin T-76.115 arvostelun

Lisätiedot

Käyttövaltuushallinnan hyödyt tehokkaasti käyttöön. Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland

Käyttövaltuushallinnan hyödyt tehokkaasti käyttöön. Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland Käyttövaltuushallinnan hyödyt tehokkaasti käyttöön Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland 1 Sisältö Skaalautuva pilvipalvelu Käyttövaltuushallinnan käyttöönotto palveluna

Lisätiedot

Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä

Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Lopullinen versio, syyskuu 2010 Paikallisen ja alueellisen tason kestävää kehitystä koskeva integroitu johtamisjärjestelmä Laajuus Jatkuva laajeneminen sekä maantieteellisesti että sisällön kannalta: Yhdestä

Lisätiedot

Toiminnallinen turvallisuus

Toiminnallinen turvallisuus Toiminnallinen turvallisuus Mitä uutta standardeissa IEC 61508 Tekn.lis. Matti Sundquist, Sundcon Oy www.sundcon.fi matti.sundquist@sundcon.fi Mitä uutta standardeissa IEC 61508-1 ja -4? IEC 61508-1 (yleistä):

Lisätiedot

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun

Lisätiedot

Laatukäsikirja - mikä se on ja miten sellainen laaditaan?

Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka

Lisätiedot

Jyväskylän yliopiston laatutyö

Jyväskylän yliopiston laatutyö Jyväskylän yliopiston laatutyö Pirjo Halonen Laatupäällikkö 17.1.2007 1 Yliopistolain Jyväskylän yliopisto velvoite 5 Arviointi Yliopistojen tulee arvioida koulutustaan, tutkimustaan sekä taiteellista

Lisätiedot

SOTILASILMAILUN TVJ-ALAN TEKNISEN HENKILÖSTÖN KELPOISUUSVAATIMUKSET

SOTILASILMAILUN TVJ-ALAN TEKNISEN HENKILÖSTÖN KELPOISUUSVAATIMUKSET SOTILASILMAILUN VIRANOMAISYKSIKKÖ FINNISH MILITARY AVIATION AUTHORITY SOTILASILMAILUMÄÄRÄYS MILITARY AVIATION REGULATION SIM-He-lv-002 versio A, muutos 0 19.12.2008 PL 30, 41161 TIKKAKOSKI, FINLAND, Tel.

Lisätiedot

MUSEOT KULTTUURIPALVELUINA

MUSEOT KULTTUURIPALVELUINA Elina Arola MUSEOT KULTTUURIPALVELUINA Tutkimuskohteena Mikkelin museot Opinnäytetyö Kulttuuripalvelujen koulutusohjelma Marraskuu 2005 KUVAILULEHTI Opinnäytetyön päivämäärä 25.11.2005 Tekijä(t) Elina

Lisätiedot

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä $$$ Raha ratkaisee On vaara rakastua tekniikkaan, myös asiakkailla Kaikki pitää pystyä perustelemaan taloudellisesti Projektin toteutus yleensä -> voidaan jättää toteuttamatta, jos ei maksa itseään takaisin

Lisätiedot

Testaajan eettiset periaatteet

Testaajan eettiset periaatteet Testaajan eettiset periaatteet Eettiset periaatteet ovat nousseet esille monien ammattiryhmien toiminnan yhteydessä. Tämä kalvosarja esittelee 2010-luvun testaajan työssä sovellettavia eettisiä periaatteita.

Lisätiedot

PALVELUKUVAUS järjestelmän nimi versio x.x

PALVELUKUVAUS järjestelmän nimi versio x.x JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen Liite 4 Palvelukuvaus -pohja Versio: 1.0 Julkaistu: 11.9.2009 Voimassaoloaika: Toistaiseksi PALVELUKUVAUS järjestelmän nimi versio

Lisätiedot

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi

Agenda. Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu ohjelmointi 1. Luento: Sulautetut Järjestelmät Arto Salminen, arto.salminen@tut.fi Agenda Johdanto Ominaispiirteitä Kokonaisjärjestelmän määrittely Eri alojen edustajien roolit Sulautetut järjestelmät ja sulautettu

Lisätiedot

TIETOTILINPÄÄTÖS. Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto. Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä

TIETOTILINPÄÄTÖS. Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto. Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä TIETOTILINPÄÄTÖS Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä 20.5.2014 TSV:n tsto/ylitarkastaja Arto Ylipartanen 2 LUENNON AIHEET 1.

Lisätiedot

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS 10 KEYS TO SUCCESSFUL SOFTWARE PROJECT 1. Clear Vision 2. Stable, Complete, Written Requirements 3. Detailed User Interface Prototypes

Lisätiedot

OHSAS vs. ISO mikä muuttuu?

OHSAS vs. ISO mikä muuttuu? OHSAS 18001 vs. ISO 45001 mikä muuttuu? Kiwa Inspecta Sini Ahlgren HSEQ-tuotepäällikkö 12.9.2018 Trust Quality Progress OHSAS 18001 vaihtuu ISO 45001 standardiksi ISO 45001: Työterveys- ja työturvallisuusjärjestelmät.

Lisätiedot

Tietoturvallisuuden kokonaisvaltainen hallinta Heikki O. Penttinen Castilsec Oy.

Tietoturvallisuuden kokonaisvaltainen hallinta Heikki O. Penttinen Castilsec Oy. Tietoturvallisuuden kokonaisvaltainen hallinta 3.12.2015 Heikki O. Penttinen Castilsec Oy Tietoturvallisuuden päätavoitteet organisaatioissa Tietoturvallisuuden oikean tason varmistaminen kokonaisvaltaisesti

Lisätiedot

Pitkäaikaissäilytyksen toiminta ja ylläpito

Pitkäaikaissäilytyksen toiminta ja ylläpito Pitkäaikaissäilytyksen toiminta ja ylläpito Museoiden KDK-ajankohtaispäivä 29.4.2010 Kimmo Koivunen CSC Tieteen tietotekniikan keskus Oy CSC IT Center for Science Ltd. Sisältö PAS kokonaisarkkitehtuurissa

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi 1 Yleistä Palvelun kehitys jakautuu vaiheisiin, joiden väleissä

Lisätiedot

Tietohallinnon nykytilan analyysi. Analyysimenetelmä (sovitettu Tietohallintomallista) 9.10.2013

Tietohallinnon nykytilan analyysi. Analyysimenetelmä (sovitettu Tietohallintomallista) 9.10.2013 Tietohallinnon nykytilan analyysi Analyysimenetelmä (sovitettu Tietomallista) 9.10.2013 Haastattelurunko Kerättävät perustiedot Budjetti (edellisvuoden) Henkilöstökustannukset IT-ostot Muut Liite - Kypsyysanalyysin

Lisätiedot

UCOT-Sovellusprojekti. Testausraportti

UCOT-Sovellusprojekti. Testausraportti UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä

Lisätiedot

SUOMEN KUNTALIITTO RY

SUOMEN KUNTALIITTO RY Karttaliittymä Versio: 18.10.2011 Julkaistu: 27.10.2011 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen tausta... 2 1.2 Suosituksen rakenne... 2 2 Soveltamisala... 2 3 Lyhenteet...

Lisätiedot

Integrated Management System. www.ims.fi, Ossi Ritola

Integrated Management System. www.ims.fi, Ossi Ritola Integrated Management System www.ims.fi, Ossi Ritola Mitä prosessien tunnistaminen on? Löydämme ja ryhmittelemme organisaation toistettavat työnkulut optimaalisimmalla tavalla organisaation tulevaisuuden

Lisätiedot

Vesihuolto päivät #vesihuolto2018

Vesihuolto päivät #vesihuolto2018 TEKNOLOGIAN TUTKIMUSKESKUS VTT OY Vesihuolto 2018 -päivät #vesihuolto2018 Kyber-turva-vesi-hanke Heimo Pentikäinen Teknologian tutkimuskeskus VTT Oy Esityksen sisältö: Perustiedot Hankkeessa laaditut ohjeet

Lisätiedot

Teollisuusautomaation standardit. Osio 2:

Teollisuusautomaation standardit. Osio 2: Teollisuusautomaation standardit Osio 2 Osio 1: SESKOn komitea SK 65: Teollisuusprosessien ohjaus Osio 2: Toiminnallinen turvallisuus: periaatteet Osio 3: Toiminnallinen turvallisuus: standardisarja IEC

Lisätiedot

Moduls: Tehokkuutta myymälärakentamiseen tehostamalla konehuonerakentamista

Moduls: Tehokkuutta myymälärakentamiseen tehostamalla konehuonerakentamista Moduls: Tehokkuutta myymälärakentamiseen tehostamalla konehuonerakentamista Konehuoneen rakentamissa on haasteita, jotka vaikuttavat suoraan kauppaketjujen liiketoimintaan HAASTEET VAIKUTUKSET RATKAISU:

Lisätiedot

Tietoturvakonsulttina työskentely KPMG:llä

Tietoturvakonsulttina työskentely KPMG:llä Tietoturvakonsulttina työskentely KPMG:llä Helsingin Yliopisto 28 Helmikuuta 2014 Agenda Agenda Työtehtävistä yleisesti Esimerkkejä Osaamisen/toiminnan kehittäminen 1 Turvallisuuden arviointi / auditointi

Lisätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot