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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IPT-hanke: Kehitysvaihe -työpaja Työpaja 5: Kokoushotelli Gustavelund 26.-27.5.2015

IPT-hanke: Kehitysvaihe -työpaja Työpaja 5: Kokoushotelli Gustavelund 26.-27.5.2015 Integroitujen projektitoimitusten kehittäminen johtavien tilaajien ryhmähankkeena (IPT-hanke) IPT-hanke: Kehitysvaihe -työpaja Työpaja 5: Kokoushotelli Gustavelund 26.-27.5.2015 IPT-hanke; kehitysvaihe-työpaja

Lisätiedot

Quality Consulting M.Mikkola OY Mari.mikkola@qcmm.fi 050-3205088

Quality Consulting M.Mikkola OY Mari.mikkola@qcmm.fi 050-3205088 Quality Consulting M.Mikkola OY Mari.mikkola@qcmm.fi 050-3205088 Laadunhallintajärjestelmän tulisi olla organisaation strateginen päätös ISO9001 tarkoituksena ei ole edellyttää, että kaikilla laadunhallintajärjestelmillä

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

Kuntasektorin kokonaisarkkitehtuuri

Kuntasektorin kokonaisarkkitehtuuri Kuntasektorin kokonaisarkkitehtuuri Yhteiskäyttöisten komponenttien kehitys ja hallinta Kurttu 18.4.2013 Ohjelmistokomponenttien uudelleenkäyttö Kustannussäästöjä» Kehityskustannukset» Lisenssikustannukset

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

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

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

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

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

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

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

OTM-HANKE. Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus

OTM-HANKE. Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus OTM-HANKE Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus Taustaa Aalto-yliopisto, Helsingin yliopiston ja Tampereen yliopiston yhteishanke opintohallinnon tietojärjestelmien modernisoinniksi

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

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

SÄHKE2-SOVELLUSAUDITOINNIT

SÄHKE2-SOVELLUSAUDITOINNIT 1 (8) Kansallisarkisto SÄHKE2-SOVELLUSAUDITOINNIT PALVELUKUVAUS v. 2.0 (21.2.2013) VERSIOHISTORIA Versio Päivämäärä Tekijä Sisältö 2.0 21.2.2013 Mikko Eräkaski Poistettu toiminta-auditointia koskeva osio

Lisätiedot

STANDARDI SFS-EN ISO 14006, YMPÄRISTÖNÄKÖKOHDAT HUOMIOON OTTAVAN SUUNNITTELUN SISÄLLYTTÄMINEN YMPÄRISTÖJÄRJESTELMÄÄN

STANDARDI SFS-EN ISO 14006, YMPÄRISTÖNÄKÖKOHDAT HUOMIOON OTTAVAN SUUNNITTELUN SISÄLLYTTÄMINEN YMPÄRISTÖJÄRJESTELMÄÄN EKOSUUNNITTELU STANDARDI SFS-EN ISO 14006, YMPÄRISTÖNÄKÖKOHDAT HUOMIOON OTTAVAN SUUNNITTELUN SISÄLLYTTÄMINEN YMPÄRISTÖJÄRJESTELMÄÄN 30.1.2013, Riitta Lempiäinen, Motiva Oy 30.1.2013 RTL JOHDANTO EKOSUUNNITTELU

Lisätiedot

Prosessien kehittäminen. Prosessien parantaminen. Eri mallien vertailua. Useita eri malleja. Mitä kehitetään?

Prosessien kehittäminen. Prosessien parantaminen. Eri mallien vertailua. Useita eri malleja. Mitä kehitetään? Prosessien kehittäminen Prosessien parantaminen Sami Kollanus TJTA330 Ohjelmistotuotanto 21.2.2007 Mitä kehitetään? CMMI, SPICE yms. Miten kehittämishanke saadaan toteutettua? Organisaation kehittämisen

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

! LAATUKÄSIKIRJA 2015

! LAATUKÄSIKIRJA 2015 LAATUKÄSIKIRJA Sisällys 1. Yritys 2 1.1. Organisaatio ja vastuualueet 3 1.2. Laatupolitiikka 4 2. Laadunhallintajärjestelmä 5 2.1. Laadunhallintajärjestelmän rakenne 5 2.2. Laadunhallintajärjestelmän käyttö

Lisätiedot

Työkalut ohjelmistokehityksen tukena

Työkalut ohjelmistokehityksen tukena 1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan

Lisätiedot

Tietoturvallisuus yhteiskunnan, yritysten ja yksityishenkilöiden kannalta

Tietoturvallisuus yhteiskunnan, yritysten ja yksityishenkilöiden kannalta Tietoturvallisuus yhteiskunnan, yritysten ja yksityishenkilöiden kannalta Sähköurakoitsijapäivät 21.11.2013 Kari Wirman 7.11.2013 Kari Wirman 21.11.2013 Kari Wirman, ICT-pooli Tieto Tieto on nyky-yhteiskunnan

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

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

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

Omavalvonta ja laadunhallintajärjestelmä. Elintarvikkeiden tarjoaminen julkisille keittiöille 16.8.12

Omavalvonta ja laadunhallintajärjestelmä. Elintarvikkeiden tarjoaminen julkisille keittiöille 16.8.12 Omavalvonta ja laadunhallintajärjestelmä Elintarvikkeiden tarjoaminen julkisille keittiöille 16.8.12 Omavalvonnan säädökset Elintarvikelain 23/2006 mukaisesti kaikilla elintarvikealan toimijoilla on oltava

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

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

EKSOTE Sähköisen asioinnin seminaari 14.10.2014

EKSOTE Sähköisen asioinnin seminaari 14.10.2014 EKSOTE Sähköisen asioinnin seminaari 14.10.2014 Sähköisen asioinnin mahdollisuudet tulevaisuudessa Sami Säisä Mitä on sähköinen asiointi? Sähköinen Internetissä toimivaa palvelua? Itsepalveluna toteutettavaa

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

Turvallisuuskulttuuri ja ydinlaitosrakentaminen

Turvallisuuskulttuuri ja ydinlaitosrakentaminen ja ydinlaitosrakentaminen - Tsernobyl 1986 - Onnettomuustutkinnan yhteydessä luotiin Turvallisuuskulttuuri -käsite - Turvallisuuskulttuuri -käsite määriteltiin 1991 ensimmäisen kerran 1991 IAEA:n (The

Lisätiedot

Portaaliteknologiat mahdollistavat ajattelutavan muutoksen

Portaaliteknologiat mahdollistavat ajattelutavan muutoksen - 1 - Portaaliteknologiat mahdollistavat ajattelutavan muutoksen Petri Kanerva Fusion Middleware Architect, Oracle Finland Oy 29.04.2010 The following is intended to outline our general

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

Toimilohkojen turvallisuus tulevaisuudessa Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot

JulkICTLab Eteneminen 2015. 4.3.2015 Mikael Vakkari, VM

JulkICTLab Eteneminen 2015. 4.3.2015 Mikael Vakkari, VM JulkICTLab Eteneminen 2015 4.3.2015 Mikael Vakkari, VM JulkICTLab lyhyesti Kokoaa yhteen julkisen hallinnon eri projektien kehittämistoimintaa Edistää palveluiden kehittämistä ja referenssitoteutusten

Lisätiedot

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Teollisuusautomaation tietoturvaseminaari Purchasing Manager, Hydro Lead Buyer, Industrial Control Systems 1 Agenda / esityksen tavoite

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

Millainen on onnistunut ICT-projekti?

Millainen on onnistunut ICT-projekti? Millainen on onnistunut ICT-projekti? Ohjelmistotuotannon lehtori Tero Tensu Ahtee Ohjelmistotekniikan laitoksella 1990- Projektityö-kurssilla 1991- pesunkestävä yliopistohampuusi ei päivääkään oikeissa

Lisätiedot

Multisite -projektit uhasta mahdollisuus? Johtamiseväitä projektipäällikölle

Multisite -projektit uhasta mahdollisuus? Johtamiseväitä projektipäällikölle Multisite -projektit uhasta mahdollisuus? Johtamiseväitä projektipäällikölle TTY / Projektinhallintapäivä 23.8.2011 Olli-Pekka Mäkirintala olli-pekka.makirintala@altonova.fi 040 5541031 Olli-Pekka Mäkirintala

Lisätiedot

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy www.softqa.fi

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy www.softqa.fi Laadukas vaatimustenhallinta Pekka Mäkinen www.softqa.fi Esityksen perusajatuksia Vaatimuksilla on elinkaari ja ne muuttuvat. Tuotteen elinkaari vaikuttaa vaatimuksiin. Vaatimusten keruussa ja -hallinnassa

Lisätiedot

OMAVALVONTA ISO 9001 ISO / FSSC 22000 ISO 14001 OHSAS 18001 SATAFOOD KEHITTÄMISYHDISTYS RY 24.9.2015. Marika Kilpivuori

OMAVALVONTA ISO 9001 ISO / FSSC 22000 ISO 14001 OHSAS 18001 SATAFOOD KEHITTÄMISYHDISTYS RY 24.9.2015. Marika Kilpivuori SATAFOOD KEHITTÄMISYHDISTYS RY Laatu- ja ympäristöjärjestelmät 24.9.2015 Marika Kilpivuori OMAVALVONTA ISO 9001 ISO / FSSC 22000 BRC ISO 14001 OHSAS 18001 IFS 1 MIKÄ JÄRJESTELMÄ MEILLÄ TARVITAAN? Yrityksen

Lisätiedot

Suomen avoimien tietojärjestelmien keskus COSS ry

Suomen avoimien tietojärjestelmien keskus COSS ry Viisaat hankinnat: Avoimuudet uusissa JIT 2015 -ehdoissa JulkICTLab-seminaari 20.11.2015 Martin von Willebrand, puheenjohtaja Avoin arkkitehtuuri Luo jäsenien menestystarinoita avoimilla ratkaisuilla Avoimet

Lisätiedot

Johtamisen standardit mitä ja miksi

Johtamisen standardit mitä ja miksi Johtamisen standardit mitä ja miksi Forum 2013 Sari Sahlberg Johtamisen standardi Auttaa organisaatiota kehittämään valittua johtamisen osa-aluetta Laadunhallinta Ympäristöasioiden hallinta Tietoturvallisuuden

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

Rakennustuotteiden -merkintä

Rakennustuotteiden -merkintä Rakennustuotteiden -merkintä Eurooppalainen käytäntö rakennustuotteiden kelpoisuuden osoittamiseen Rakennustuotteiden CE-merkintä perustuu rakennustuotedirektiiviin Euroopan komission rakennustuotedirektiivin

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

Hyväksytyt asiantuntijat

Hyväksytyt asiantuntijat 1(4) Hyväksytyt asiantuntijat Pätevyysalue Pätevyysluokat Tarkastuskohteet Tässä muistiossa käsitellään ajoneuvolain 1090/2002 (muutettuna viimeksi 1042/2014) 48 2 momentin nojalla Liikenteen turvallisuusviraston

Lisätiedot

Luku 10 Käyttöönoton suunnitteluja toteutusvaihe

Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Käyttöönoton Roll-Out Planning suunnittelu- & Preparation ja valmistelu Design Tiedon- Data Conversion muunnos- prosessien Processes suunnittelu Toimipisteiden

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

Tampereen kaupungin paikkatietostrategia 2013 2015. Tampereen kaupunki

Tampereen kaupungin paikkatietostrategia 2013 2015. Tampereen kaupunki Tampereen kaupungin paikkatietostrategia 2013 2015 Tampereen kaupunki 28.3.2013 TAMPERE Tampereen kaupungin paikkatietostrategia 1 PAIKKATIETO JA PAIKKATIETOINFRASTRUKTUURI KÄSITTEENÄ Paikkatiedolla tarkoitetaan

Lisätiedot

MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla

MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla Tervetuloa mukaan Sisällysluettelo yleistä... 3 MY KNX... 3 Kirjaudu KNX organisaation kotisivulle... 4 Partnerluettelo... 5

Lisätiedot

SÄHKÖTEKNIIKAN KOULUTUSOHJELMA 2010

SÄHKÖTEKNIIKAN KOULUTUSOHJELMA 2010 SÄHKÖTEKNIIKAN KOULUTUSOHJELMA 2010 Sähkötekniikan koulutusohjelman toimintaympäristö ja osaamistavoitteet Sähkötekniikan koulutusohjelma on voimakkaasti poikkialainen ja antaa mahdollisuuden perehtyä

Lisätiedot

Standardien PCI DSS 3.0 ja Katakri II vertailu

Standardien PCI DSS 3.0 ja Katakri II vertailu Standardien PC DSS 3.0 ja Katakri vertailu Copyright Solinor Oy 2014 Solinor Oy, Teollisuuskatu 21 A, F-00510 HELSNK, FNLAND +358 10 279 2940 / www.solinor.com / Business D 17967170 Standardien PC DSS

Lisätiedot

Miten kerätä tietoa toiminnan jatkuvaan kehittämiseen

Miten kerätä tietoa toiminnan jatkuvaan kehittämiseen Miten kerätä tietoa toiminnan jatkuvaan kehittämiseen Tuija Sinervo FINAS - akkreditointipalvelu Mitä kehitetään? Asiakaspalvelua Osaamista Toiminnan sujuvuutta, tehokkuutta Tekniikkaa, toimintaympäristöä

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

TIETOTEKNIIKAN KOULUTUSOHJELMA

TIETOTEKNIIKAN KOULUTUSOHJELMA TIETOTEKNIIKAN KOULUTUSOHJELMA Tietotekniikan koulutusohjelman toimintaympäristö ja osaamistavoitteet Tietotekniikan koulutusohjelmasta valmistuneet insinöörit sijoittuvat suunnittelu-, ohjelmointi-, esimies-,

Lisätiedot

Tietokantojen suunnittelu, relaatiokantojen perusteita

Tietokantojen suunnittelu, relaatiokantojen perusteita Tietokantojen suunnittelu, relaatiokantojen perusteita A277, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin

Lisätiedot

BIMin mahdollisuudet hukan poistossa ja arvonluonnissa LCIFIN Vuosiseminaari 30.5.2012

BIMin mahdollisuudet hukan poistossa ja arvonluonnissa LCIFIN Vuosiseminaari 30.5.2012 BIMin mahdollisuudet hukan poistossa ja arvonluonnissa LCIFIN Vuosiseminaari 30.5.2012 RIL tietomallitoimikunta LCI Finland Aalto-yliopisto Tampereen teknillisen yliopisto ja Oulun yliopisto Tietomallien

Lisätiedot

Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena

Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Mittaaminen ja ohjelmistotuotanto seminaari 18.04.01 Matias Vierimaa 1 Miksi mitataan? Ohjelmistokehitystä ja lopputuotteen laatua on vaikea arvioida

Lisätiedot

Mikkelin sähköisen asioinnin alusta - päätöksenteko. Kalle Launiala / ProtonIT Oy kalle.launiala@protonit.net +358 44 5575665

Mikkelin sähköisen asioinnin alusta - päätöksenteko. Kalle Launiala / ProtonIT Oy kalle.launiala@protonit.net +358 44 5575665 Mikkelin sähköisen asioinnin alusta - päätöksenteko Kalle Launiala / ProtonIT Oy kalle.launiala@protonit.net +358 44 5575665 Esityksen osat Hankemallista jatkuvaan ylläpitoon Etenemisehdotus sidosryhmien

Lisätiedot

AEO-Toimijapäivä. Toimitusketjujen uhkien analysointi ja riskienhallinta yhteistyössä sopimuskumppanien kanssa 12.3.2013.

AEO-Toimijapäivä. Toimitusketjujen uhkien analysointi ja riskienhallinta yhteistyössä sopimuskumppanien kanssa 12.3.2013. AEO-Toimijapäivä Toimitusketjujen uhkien analysointi ja riskienhallinta yhteistyössä sopimuskumppanien kanssa 12.3.2013 Sami Hyytiäinen Johdanto Turvallisuus ja vaarattomuus toimitusketjussa Kuljetusketjun

Lisätiedot

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa 13.05.2015 Terveydenhuollon ATK-päivät Tampere-talo Yleistä Riskienhallintaan löytyy viitekehyksiä/standardeja kuten ISO 31000

Lisätiedot

Projektiryhmä Tete Työajanseurantajärjestelmä. Versionhallintasuunnitelma

Projektiryhmä Tete Työajanseurantajärjestelmä. Versionhallintasuunnitelma Projektiryhmä Tete Työajanseurantajärjestelmä T-76.115 Tietojenkäsittelyopin ohjelmatyö 2(7) Muutoshistoria Version Date Author Description 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja 0.20 19.10.2003

Lisätiedot

Rosemount 3051S sähköiset ERS-anturit

Rosemount 3051S sähköiset ERS-anturit sähköiset ERS-anturit Uudentasoiset mittausratkaisut erityiskohteisiin Uusi ratkaisu vanhaan ongelmaan Kaikkialta löytyy mittauksia, joiden luotettava toiminta edellyttää sekä aikaa että voimavaroja. Tyypillisiä

Lisätiedot