hyväksymispäivä arvosana arvostelija Konfiguraationhallinta ja Rational ClearCase Juha Kuosmanen Helsinki 15.11.2000 Ohjelmistotuotantonvälineet-seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
1 Sisältö 1 Johdanto...2 2. Konfiguraationhallinnan tarkoitus...2 3. Kantaversio...3 4. Ohjelmistotuotteen hallinnan osa-alueet...5 4.1 Ohjelmistoalkioiden tunnistus...5 4.2 Kokoonpanon ja muutoksenhallinta...6 4.3 Kokoonpanon tarkistus...6 4.4 Tilanteen seuranta ja raportointi...7 4.5 Versionhallinta...7 5. ClearCase ja nykyaikainen konfiguraationhallinnan tuki...8 5.1 Versionhallinta...8 5.2 Työtilan hallinta...8 5.3 Ohjelmistoversion rakentamisen hallinta...9 5.4 Prosessin hallinta...9 6. Yhteenveto...10 Lähteet
2 1 Johdanto Ohjelmistotuotteen konfiguraationhallinta (Software Configuration Management, SCM) on ohjelmistotieteen osa-alue, joka yhdistää työkalut, tekniikat, prosessit ja menetelmät, joita yritykset käyttävät hallitakseen ohjelmistoihin sitoutunutta omaisuuttaan [Whi00]. Johdantoosuus IEEE:n standardiin "Ohjelmistojen konfiguraation suunnittelu" kuvaa konfiguraationhallintaa seuraavasti: "Konfiguraationhallinta muodostaa hyvän insinöörikäytännön kaikkiin ohjelmistoprojekteihin oli kyseessä sitten vaiheistettu toimitus, prototyypitys tai jatkuva ylläpito. Konfiguraationhallinta parantaa ohjelmistojen laatua ja luotettavuutta: Luomalla rakenteen dokumentaation, ohjelmakoodin, rajapintojen ja tietokantojen tunnistamiseksi ja kehityksen tukemiseksi. Tukemalla yrityksen vaatimuksiin, standardeihin, organisatioon ja johtamisidelogiaan liittyvää kehitys- tai ylläpitomenetelmää. Tuottamalla hallinnollista- sekä tuoteinformaatiota mm. ohjelmiston muutoksenhallintaan, testaukseen, toimituksiin ja auditointeihin liittyen. 2. Konfiguraationhallinnan tarkoitus Ohjelmistojen konfiguraationhallinta auttaa vähentämään ohjelmistokehitykseen liittyviä ongelmia kontrolloimalla ja koordinoimalla projektissa toimivien ihmisten työtuotteita (work products) [Hum90]. Ilman tarvittavaa kontrollia projektin työtuotteisiin voi syntyä ongelmia aiheuttavia ristiriitoja. Esimerkkejä tällaisista ristiriidoista ovat mm.: Yhtäaikaiseen päivitykseen liittyvät ongelmat: Kaksi tai useampi ohjelmoija muuttaa yhtäaikaisesti samaa ohjelman osaa, jolloin viimeisen tallennuksen tekijä voi vahingossa tuhota jo aikaisemmin tehdyt muutokset.
3 Jaettuun tai yhteiseen koodiin liittyvät ongelmat: Koodiin tehdyistä muutoksista ei muisteta tiedottaa kaikille kiinnostuneille osapuolille. Versioihin liittyvät ongelmat: Laajoja ohjelmistoja kehitetään yleensä evolutionäärisesti. Yksi ohjelman julkistus (release) voi olla asiakkaiden käytössä, toinen testauksessa ja kolmas edelleen kehityksen alaisuudessa. Jos asiakasjulkistuksesta löydetään virhe, se on korjattava myös testauksessa ja kehityksessä oleviin versioihin. Yhtälailla, jos virhe löydetään kehitysversiosta, se on korjattava kaikkiin aikaisempiin versioihin. Laajoissa ohjelmistoissa eri versioihin liittyvien korjausten ja parannusten koordinointi on erittäin haastava ongelma. Konfiguraationhallinnan voidaan katsoa olevan joukko jäljitys- ja kontrollointitoimintoja (tracking and control), jotka alkavat kun ohjelmistoprojekti alkaa ja päättyy vasta ohjelmiston elinkaaren loppuessa. 3. Kantaversio Kantaversio (baseline) on konfiguraationhallinnan perusta [Hum90]. Kantaversio määrittää tuotteen virallisen version, jonka pohjalle jatkotyö perustuu. IEEE määrittää kantaversion seuraavasti: "Kantaversio on spesifikaatio tai tuote, joka on virallisesti katselmoitu ja joka toimii tulevan kehityksen perustana. Kantaversiota voidaan muuttaa vain virallisen muutoksenhallintamenettelyn kautta.
4 Initial Development Requirements/ Design/Use Establish/ Update Baseline Approve Change Validate Baseline Authorize Change Implement Change Validate Change Baselines & Changes Kuva1: Yleiskuva konfiguraationhallintaan [Hum90] Kun ensimmäinen kantaversio on luotu ja jäädytetty, jokainen muutos tallennetaan ns. Deltaversiona, kunnes uusi kantaversio on asetettu [Hum90]. Delta-tallennuksessa tiedostoista tallennetaan yleensä vain ensimmäinen versio ja seuraavista versioista vain versioiden väliset erot. Jokaisen projektin alkuvaiheessa on suositeltavaa luoda ohjelmiston kantaversio. Jos kantaversio luodaan kuitenkin liian aikaisin, se lisää turhaa byrokratiaa ja hidastaa ohjelmistosuunnittelijoiden työtä. Kantaversion luonti ei ole tarpeellista niin kauan kun suunnittelijat voivat työskennellä omien moduliensa parissa itsenäisesti. Versioiden formaali kontrollointi muuttuu välttämättömäksi, kun moduulien välinen interaktio alkaa lisääntymään.
5 4. Ohjelmistotuotteen hallinnan osa-alueet Konfiguraationhallinta käsittää joukon toimintoja ja aktiviteetteja, joita sovelletaan koko ohjelmistoprosessin ajan [Pre97]. Ohjelmistoon kohdistuvien muutospaineiden takia konfiguraationhallinnan toimintojen tarkoituksena on: Tunnistaa muutoksen tarve Kontrolloida muutosta Varmistua siitä, että muutos on toteutettu asianmukaisesti Raportoida muutoksesta kiinnostuneille osapuolille. 4.1 Ohjelmistoalkioiden tunnistus Ohjelmistoalkio (Software Configuration Item, SCI) on pienin ohjelmistotuotteen hallinnassa oleva kokonaisuus. Tavallisesti ohjelmistoalkio tarkoittaa yksittäistä tiedostoa, mutta useampikin tiedosto voi muodostaa yhden alkion. Ohjelmistoalkiot voidaan jakaa kahteen luokkaan perusalkiot (basic objects) ja koontialkiot (aggregate objects) [Pre97]. Ohjelmiston kokoonpanon tietyllä hetkellä jäädytetty versio on kantaversio (baseline). Laaja ohjelmistokokonaisuus voi käsittää tuhansia eri tiedostoja ja dokumentteja. Näistä kaikista voi olla useita kymmeniä eri versioita kustakin. Ohjelmistoalkioiden nimet ja versiot pitääkin pystyä tunnistamaan yksikäsitteisesti, jotta vältyttäisiin sekaannuksilta. Ohjelmistoalkiosta täytyy tunnistaa alkion version ja variantin lisäksi alkion käyttökohteet. Tunnistamisen pitää olla kaksisuuntaista. Valmiista ohjelmistopaketista pitää pystyä tunnistamaan ne ohjelmistoalkiot (lähdekoodit, dokumentit) joista se koostuu.
6 4.2 Kokoonpanon ja muutoksenhallinta Ohjelmistoprojekteissa hallitsematon muutos johtaa nopeasti kaaokseen. Kokoonpanon hallinta kontrolloi ohjelmistoalkioiden kehitystä ja niiden välisiä suhteita. Kokoonpanon hallinta onkin suurelta osin muutosten hallintaa. Muutosten hallintaa tarvitaan, jotta ohjelmistoon liittyvät muutokset voidaan hyväksyä ja rekisteröidä. Muutokset tulevat myös paremmin näkyviksi ja helpommin ymmärrettäviksi, jos ne käsitellään aina samalla tavalla. Jokaisessa ohjelmistoprojektissa tulisi olla nimetty henkilö vastaamaan muutosten hallinnastaan liittyvistä menettelyistä. Menettelyssä tulee noudattaa organisaatiossa yleisesti hyväksyttyjä periaatteita. Muutosten hallinta tulisi ulottaa kaikeen materiaaliin, joka liittyy ohjelmistoon: dokumentaatio, määrittelyt, lähdekoodi, suunnitelmat ja käyttöohjeet. Suuremmissa projekteissa muutoksenhallinta alistetaan yleensä muutoksenhallintalautakunnan (Change Control Board, CCB) alaisuuteen. Lautakunnan tarkoituksena on huolehtia, että muutokset perusversioon ovat harkittuja ja että niistä tiedotetaan kaikille kiinnostuneille osapuolille [Hum90]. 4.3 Kokoonpanon tarkistus Kokoonpanon tarkistus on läheisesti tekemisissä laadun tarkastuksen ja valvonnan kanssa. Kokoonpanon tarkastus käsittää kaiken ohjelmistoon kuuluvan materiaalin tarkastuksen. Dokumentit ja lähdekoodit luetaan läpi, mahdolliset virheet tai epäjohdonmukaisuudet korjataan ennen hyväksyntää. Kokoonpanon tarkastuksessa tarkastetaan, että ohjelmisto täyttää standardit ja on tehty organisaatiossa voimassaolevien ohjeiden mukaisesti.
7 4.4 Tilanteen seuranta ja raportointi Tilanteen seuranta vastaa kysymyksiin [Pre97]: Mitä tapahtui? Kuka teki muutoksen? Milloin muutos tehtiin? Mihin muutos vaikuttaa? Tilanteen seuranta mahdollistaa organisaatiossa kertyneen kokemuksen hyödyntämisen seuraavia projekteja käynnistettäessä. Tilanteen seuranta kerää ja tallentaa tietoa kaikista kokoonpanoon kuuluvista alkioista sekä kaikista kokoonpanoon ehdotetuista ja hyväksytyistä muutoksista. Myös alkioiden elinkaaren tilaa seurataan, jotta ohjelmistokokonaisuuden valmiusaste saataisiin selville. 4.5 Versionhallinta Ohjelmistonversion hallinta yhdistää ne menetelmä ja työkalut, joiden avulla eri ohjelmistoalkioiden versioita hallitaan ohjelmistotuotantoprosessin aikana [Pre97]. Versionhallinan keskeinen tehtävä on alunperin ollut päällekäisen päivityksen ongelman poistaminen. Versionhallinta ei itsessään ota mitään kantaa eri tiedostojen välisiin riippuvuuksiin. Ohjelmiston kokoonpanon hallinta perustuu kuitenkin käyttäjien mahdollisuuteen määrittää useita eri ohjelmistokokoonpanoja versioiden valinnan kautta. Jokaiseen ohjelmistoalkion versioon liittyy useita attribuutteja, joiden perusteella eri kokoonpanoja voidaan muodostaa ja hallita.
8 5. ClearCase ja nykyaikainen konfiguraationhallinnan tuki Clearcase on konfiguraationhallinnan työkalu, joka tarjoaa automatisoituja palveluita ja tukea konfiguraationhallintaan. ClearCase mahdollistaa ns. yleisen- sekä valmisratkaisun konfiguraation hallintaan. Yleisessä ratkaisussa ClearCase olettaa hyvin vähän käytössä olevalta kehitysprosessilta ja ympäristöltä. ClearCasen valmismalli pohjautuu Rational Softwaren kehittämään Unified Change Management (UCM) ratkaisuun. Ennen ClearCasen asennusta ja käyttöönottoa käyttäjän tarviikin päättää haluaako hän räätälöidä oman mallinsa vai käyttää UCM-mallia [Rat99]. ClearCasen neljä perustoimintoa ovat versionhallinta (version control), työtilan hallinta (workspace management), ohjelman rakennuksen hallinta (build management) sekä prosessin hallinta (process control). 5.1 Versionhallinta ClearCasen versionhallinta käsittää kaikkien ohjelmistokomponenttien (lähdekoodi, binäärikoodi, dokumentaatio, testitapaukset, kirjastot ja muut käyttäjän määrittämät objektit.) hallinnan [Rat99]. ClearCase jäljittää muutoksia kaikissa tiedostoissa ja hakemistoissa sekä mahdollista helpon versioihin liittyvän ohjelmistoalkioiden tunnistamisen, rakentamisen tai takaisin palauttamisen (roll-back). 5.2 Työtilan hallinta Eräs konfiguraationhallinnan keskeisistä toiminnoista on ohjelmistokehittäjän työtilan (workspace) hallinta. Työtila on kopio kaikista oikeista versioista liittyen oikeisiin tiedostoihin ja oikeisiin hakemistoihin. ClearCasessa työtiloja kutsutaan näkymiksi (views)
9 [Whi00]. ClearCase tarjoaa kaksi eri näkymää: tilannekuvan (snapshot) ja dynaamisen (dynamic) näkymän. Tilannekuvassa tiedostojen kopiot ladataan käyttäjän työasemaan ClearCase kuvauskannasta (Version Object Base, VOB). Työtilan lataaminen kestää kauemmin ja vaatii enemmän paikallista levytilaa kuin dynaaminen näkymä, mutta toisaalta uuden ohjelmistoversion rakentamiseen liittyvä suorituskyky (build performance) on huomattavasti parempi, koska verkkoyhteyttä ei tarvita. Dynaaminen näkymä viittaa tiedostoihin suoraan kuvauskannassa. Kopiointioperaatiota ei tarvita, joten näkymän lataaminen on nopeaa ja vaatii hyvin vähän paikallista levytilaa. ClearCase tukee Visual Basic, Visual C++, Visual J++, Oracle Developer/2000, PowerBuilder and HP Softbench IDE-kehitysympäristöjä. 5.3 Ohjelmistoversion rakentamisen hallinta Moderni ohjelmistoversion rakentamisen ja julkaisun hallinta (build and release management) varmistaa, että tärkeät ohjelmistojulkaisut voidaan rakentaa uudelleen ja että julkaisuja voidaan ylläpitää helposti. ClearCase tuottaa automaattisesti materiaaliluettelon (Bill Of Material, BOM), joka dokumentoi julkaisun sisältämät ohjelmistoalkiot. Materiaaliluettelon avulla mikä tahansa ohjelmistojulkaisun tuotantoympäristö voidaan luoda uudestaan täysin samanlaisena. ClearCase on täysin yhteensopiva WinNT- ja UNIX-ympäristöissä toimivien make-ohjelmien kanssa, joten jo olemassa olevia rakentamisskriptejä (build scripts) voidaan käyttää ClearCase ympäristössä ilman mitään muutoksia. 5.4 Prosessin hallinta
10 ClearCase tarjoaa joustavia työkaluja projekti- ja sijaintipaikkakohtaisia menettelytapoja tukevien prosessien rakentamiseksi. Organisaatiot voivat automatisoida ja toteutaa rutiineita seuraamaan ohjelmistossa tapahtuvia muutoksia, estää muutoksien tekemisen perustuen käyttäjien oikeuksiin, ilmoittaa ohjelmistossa tapahtuneista muutoksista tai rekisteröidä ohjelmistokehitykseen liittyviä tapahtumia. 6. Yhteenveto Ohjelmistojen konfiguraationhallinta on keskeinen osa nykyaikaista ohjelmistotyötä. Laajoja ohjelmistokokonaisuuksia rakennettaessa konfiguraationhallinta on välttämätöntä. Konfiguraationhallintaan liittyviä työvälineitä on tarjolla useanlaisia. Rational ClearCase edustaa työvälinettä, joka tukee lähinnä versionhallintaa, työtilan hallintaa, ohjelmiston rakennuksen hallintaa ja prosessin hallintaa. Tähän tarkoitukseen ClearCase on hyvä ja monipuolinen työväline. Työväline ei kuitenkaan itsessään ratkaise konfiguraationhallintaan liittyviä ongelmia. Suurin työmäärä ja panostus liittyykin konfiguraationhallinnan menetelmien ja prosessien määrittelyyn ja suunnitteluun. Kun nämä menetelmät ja prosessit ovat vakiintuneita voidaan manuaalista työtä vähentää automatisoimalla tiettyjä toimintoja vaikkapa ClearCasen avulla. Lähteet Hum90 Pre97 Rat99 Whi00 Humphrey, Watts S., Managing the Software Process, Addison-Wesley, United States, 1990 Pressman, Roger S., Software Engineering A Practitioner's Approach, McGraw-Hill, United States, 1997 Managing software projects with ClearCase Release 4.0 and later, Rational Software, United States, 1999 White Brian.A., Software configuration management strategies and Rational ClearCase, Addison-Wesley, United States, 2000
11