MIKKO AHO KONFIGURAATIONHALLINTA AUTOMAATIOJÄRJESTELMÄ- PROJEKTEISSA Diplomityö

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

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.

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.

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

V SISÄLLYS TIIVISTELMÄ...II ABSTRACT... III ALKUSANAT...IV SISÄLLYS... V TERMIEN MÄÄRITELMÄT... VII 1. JOHDANTO... 11 2. PERUSTEET... 12 2.1 MONIMUTKAISUUS JA SEN HALLINTA AUTOMAATIOJÄRJESTELMÄKOKONAISUUKSISSA... 12 2.2 KONFIGURAATIONHALLINNAN MÄÄRITELMÄ JA PERUSKÄSITTEET... 14 2.2.1 Konfiguraatioyksikkö... 15 2.2.2 Perustaso... 17 2.2.3 Konfiguraationhallinnan suunnitelma... 18 2.2.4 Tuotteen konfiguraation informaatio... 18 2.2.5 Konfiguraationhallinnan perustoiminnot... 19 2.3 LYHYT HISTORIA... 20 2.4 OHJELMISTOJEN KONFIGURAATIONHALLINTA... 20 2.5 KONFIGURAATIONHALLINTAAN KÄYTETTÄVÄT OHJELMISTOTYÖKALUT... 21 2.6 KONFIGURAATIONHALLINNAN TUOMIA HYÖTYJÄ... 22 2.7 MAHDOLLISIA ONGELMIA, JOS KONFIGURAATIONHALLINTAA EI KÄYTETÄ... 23 2.7.1 Jaetun tiedon ongelma... 23 2.7.2 Moninkertaisen ylläpidon ongelma... 24 2.7.3 Samanaikaisen kehityksen ongelma... 24 2.7.4 Muita ongelmia... 24 2.8 IHMINEN KONFIGURAATIONHALLINNAN SUURIMPANA HAASTEENA... 25 3. PROJEKTIT JA KONFIGURAATIONHALLINTA... 27 3.1 PROJEKTIN MÄÄRITELMÄ JA SIDOSRYHMÄT... 27 3.2 PROJEKTIN ELINKAARIMALLIT... 28 3.3 AUTOMAATIOJÄRJESTELMÄN ELINKAARIMALLI... 29 3.3.1 Turvallisuuteen liittyvät järjestelmät... 31 3.3.2 Ydinvoimalan automaatiojärjestelmähankintaprojektin vaiheet... 34 3.4 SYSTEEMIN ELINKAAREN PROJEKTIPROSESSIT... 35 3.5 KONFIGURAATIONHALLINNAN TOTEUTUKSEN VAIHEET JÄRJESTELMÄN TOIMITUSPROJEKTISSA 37 4. STANDARDIT JA OHJEET... 39 4.1 YLEISTÄ STANDARDEISTA... 39 4.2 KONFIGURAATIONHALLINNAN STANDARDIT JA OHJEET... 40 4.2.1 ANSI/EIA-649-A 2004... 40 4.2.2 ANSI/EIA-836A:2008... 40 4.2.3 IEEE Std 828-1990... 41 4.2.4 ISO-10007:2003... 42 4.2.5 MIL-STD-973... 42 4.2.6 MIL-HDBK-61A(SE)... 43 5. PROJEKTIORGANISAATIOIDEN TOIMINTATAVAT JA KONFIGURAATIONHALLINTA.. 44 5.1 KONFIGURAATIONHALLINNAN TOIMINNAN JÄRJESTÄMINEN ORGANISAATION SISÄLLÄ... 44 5.1.1 Konfiguraationhallinnan tiimin organisointi... 44 5.1.2 Konfiguraationhallinnan lautakunnan organisointi... 45 5.2 TOIMINTAKULTTUURIEN PUUTTEET JA HAASTEET... 46

VI 5.2.1 Osaaminen... 46 5.2.2 Kommunikointi... 46 5.2.3 Resurssien oikea kohdistaminen... 46 5.2.4 Sitoutuminen... 47 5.2.5 Koulutus... 47 5.3 TOIMITUSKETJUN RAKENNE JA SEN VAIKUTUKSIA KONFIGURAATIONHALLINTAAN... 48 5.3.1 Vertikaalinen integraatio... 48 5.3.2 Toimitusverkoston rakenteen muuttaminen... 50 5.4 KONFIGURAATIONHALLINNAN SYNKRONOINTI PROJEKTIN OSAPUOLTEN VÄLILLÄ... 51 6. ASIANTUNTIJAHAASTATTELUT... 53 6.1 KONFIGURAATIONHALLINNAN SUUNNITELMA... 53 6.2 KONFIGURAATION TUNNISTAMINEN... 54 6.3 MUUTOKSENHALLINTA... 54 6.4 TILATIEDON HALLINTA JA KONFIGURAATIONHALLINTAAN KÄYTETTÄVÄT TYÖKALUT... 54 6.5 KONFIGURAATIONHALLINTAAN LIITTYVÄT AUDITOINNIT JA KATSELMUKSET... 55 6.6 RAJAPINTOJEN HALLINTA... 55 6.7 RESURSSIT JA AIKATAULUT... 55 6.8 ALIHANKKIJOIDEN JA TOIMITTAJIEN HALLINTA... 55 6.9 OLKILUOTO 3-PROJEKTISTA SAATUJA KOKEMUKSIA KONFIGURAATIONHALLINTAAN LIITTYEN... 55 7. KONFIGURAATIONHALLINNAN SUUNNITELMAN OHJEELLINEN SISÄLTÖ... 56 7.1 TAUSTAA... 56 7.2 JOHDANTO... 58 7.3 KONFIGURAATIONHALLINNAN JOHTAMINEN... 58 7.4 KONFIGURAATIONHALLINNAN TOIMINNOT... 60 7.4.1 Konfiguraation tunnistaminen... 61 7.4.2 Konfiguraation muutoksenhallinta... 64 7.4.3 Konfiguraation tilatiedon hallinta... 66 7.4.4 Konfiguraation katselmukset ja auditoinnit... 67 7.4.5 Rajapintojen hallinta... 68 7.4.6 Alihankkijoiden ja toimittajien hallinta... 70 7.4.7 Tuotanto...71 7.4.8 Prosessien hallinta... 71 7.4.9 Tiimityöskentely... 71 7.5 KONFIGURAATIONHALLINNAN AIKATAULUT... 72 7.6 KONFIGURAATIONHALLINNAN RESURSSIT... 72 7.7 KONFIGURAATIONHALLINNAN SUUNNITELMAN YLLÄPITO... 72 8. JOHTOPÄÄTÖKSET... 74 LÄHTEET... 76 LIITTEET... 80

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

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)

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)

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 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 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 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 1. 2. 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 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 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. 2.2.1 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 tukitoiminnoissa käytettäviä elementtejä kuten esimerkiksi käyttöjärjestelmiä ja ohjelmointityökaluja (IEEE Std 828-1990). 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 6.1.3 Konfiguraationhallinnan toiminnot esitetään yksi esimerkki tarkastuslistasta, jota voidaan käyttää apuna konfiguraatioyksiköitä valittaessa.

17 2.2.2 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 vittaessa, jolloin tuotetta kutsutaan lievennetyksi tuotteeksi (engl. deviation, waiver). (MIL-STD-973) 2.2.3 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. 2.2.4 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 Kuva 3. Tuotteen konfiguraation informaatio (ANSI/EIA-649-A 2004) 2.2.5 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 raationhallinnan suunnitelmassa. Näitä muita konfiguraationhallinnan toimintoja voivat olla esimerkiksi rajapintojen hallinta, alihankkijoiden ja toimittajien hallinta, tuotanto, prosessien hallinta ja tiimityöskentely. (IEEE Std 828-1990; 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)