MIKKO AHO KONFIGURAATIONHALLINTA AUTOMAATIOJÄRJESTELMÄ- PROJEKTEISSA Diplomityö
|
|
- Hannu-Pekka Nurminen
- 8 vuotta sitten
- Katselukertoja:
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
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ätiedotOhjelmistotuotteen 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ätiedotISO 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ätiedotOhjelmointitekniikka 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ätiedotABB 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ätiedotKONEAUTOMAATION 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ätiedotSoftware 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ätiedotJohdantoluento. 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ätiedotMenetelmä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ätiedotOhjelmistoprosessit 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ätiedotSisää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ätiedotSFS, 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ätiedotArkkitehtuurikuvaus. 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ätiedotRiippumattomat 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ätiedotProjektin 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ätiedotMikä 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ätiedotAvoimen 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ätiedotLAADUNVALVONTAJÄ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ätiedotMylab 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ätiedotEnterprise 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ätiedotRAIN 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ätiedotTestaaminen 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ätiedotJussi 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ätiedotOhjelmistotekniikka 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ätiedotAVOIMEN 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ätiedotJulkaisun 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ätiedotADE 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ätiedotLaboratorion 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ätiedotSFS-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ätiedotOhjelmistojen 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ätiedotAlkuraportti. 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ätiedotAvoimen 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ätiedotArviointi 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ätiedotStandardi 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ätiedotTietojä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ätiedotYhteenveto 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ätiedotSisää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ätiedotITSM. 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ätiedotSYSTEEMIJOHTAMINEN! 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ätiedotRiski = 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ätiedotTakki. 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ätiedotOhjelmistojen 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ätiedotOhjelmiston 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ätiedotJä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ätiedotLehtori, 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ätiedotMiksi 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ätiedotTOIMIJAREKISTERIN 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ätiedotOppivat 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ätiedotLiite 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ätiedotTARKASTUSMENETTELYT 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ätiedotSoftware 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ätiedotTulevaisuuden 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ätiedotAvoimen 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ätiedotCopyright 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ätiedotSMS 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ätiedotJulkisen 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ätiedotSoft 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ätiedotitsmf 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ätiedotKehittää 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ätiedotPotilasturvallisuuden 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ätiedotSOVELLUSALUEEN 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ätiedotProjektin 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ätiedotAuditointi. 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ätiedotHP 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ätiedotPeriaatteet 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ätiedotEMCS-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ätiedotHarjoitustyö 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ätiedotLaatu 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ätiedottsoft 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ätiedotIntegrointi. 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ätiedot4.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ätiedotPS-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ätiedotKä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ätiedotLopullinen 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ätiedotToiminnallinen 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ätiedotHELIA 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ätiedotLaatukä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ätiedotJyvä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ätiedotSOTILASILMAILUN 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ätiedotMUSEOT 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 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ätiedotTestaajan 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ätiedotPALVELUKUVAUS 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ätiedotAgenda. 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ätiedotTIETOTILINPÄÄ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ätiedotPROJEKTIN 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ätiedotOHSAS 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ätiedotTietoturvallisuuden 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ätiedotPitkä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ätiedotJHS 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ätiedotTietohallinnon 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ätiedotUCOT-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ätiedotSUOMEN 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ätiedotIntegrated 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ätiedotVesihuolto 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ätiedotTeollisuusautomaation 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ätiedotModuls: 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ätiedotTietoturvakonsulttina 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ätiedotTutkittua 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