TUOTTEENHALLINTA
Tuotteenhallinta jaetaan versiohallintaan, kokoonpanon hallintaan ja muutosten hallintaan. Jatkossa versiohallintaa ja kokoonpanon hallintaa kutsutaan yhteisnimellä "versiohallinta".
Muutosten hallinta
Muutospyyntöjen hallinta
Muutospyynnöt jaetaan usein kirjallisuudessa erikseen vikaraportteihin ja (varsinaisiin) muutospyyntöihin. Käyttäjien on kuitenkin usein vaikea erottaa vikaa parannusehdotuksesta ja tämän takia nämä kannattaa yleensä yhdistää "muutospyynnöksi".
Muutospyyntöjä lähettävät asiakkaan henkilökunta, muut mahdolliset käyttäjät ja toimittajan henkilökunta.
Muutospyynnöstä on käytävä ilmi ainakin seuraavat seikat:
- päiväys
- ilmoituksen tekijä, hänen organisaationsa ja yhteystietonsa
- ohjelmisto ja sen versio
- selitys ongelmasta
- ilmoittajan käsitys tarvittavan ylläpitoimen laadusta:
- korjaava ylläpito (virheiden käsittely),
- mukauttava ylläpito (järjestelmän mukauttaminen muuttuneeseen ympäristöön) ja
- parantava ylläpito (toiminnallinen laajentaminen ja toiminnan tehostaminen)
- ilmoittajan käsitys muutoksen kiirellisyydestä
Selkeintä on käyttää erityistä muutospyyntölomaketta.
Projektipäällikkö tarkistaa ilmoittajan luokitukset ja päättää jatkotoimenpiteestä, joka voi olla
- opastuksen antaminen ilmoittajalle (käyttövirheen tapauksessa)
- muutospyynnön yhdistäminen toiseen muutospyyntöön
- muutospyynnön ottaminen jatkokäsittelyyn
- muutospyynnön jatkokäsittelystä luopuminen
Jos muutospyyntö johtaa jatkokäsittelyyn, perustelee projektipäällikkö muutoksen tarpeellisuuden ja arvioi muutoksen vaatiman työmäärän. Mikäli muutos voidaan tehdä tai olla tekemättä, niin tarvitaan yksityiskohtaiset tiedot ratkaisun vaikutuksista.
Muutosten valvontaryhmä (jossa on myös asiakkaan edustus) päättää mitkä muutokset todella tehdään. Tehtävät muutokset niputetaan yhdessä tehtävien ryhmiin.
Muutoksista, joita ei tehdä heti, on muodostettava tulevien muutosten lista, jotta tekijät voivat varautua näihin jo muita osia tehdessään.
Mikäli muutos on järjestelmän jatkuvan toiminnan turvaamiseksi tehtävä välittömästi, voi projektipäällikkö antaa muutosmääräyksen pikamääräyksenä. Tästä huolimatta muutos on lisäksi käsiteltävä normaalimenettelyllä.
Ylläpitotyöryhmä suorittaa muutokset projektipäällikön johdolla. Tässä työssä noudatetaan normaaleja elinkaaritoimintoja.
Muutospyyntöjen byrokraattisen hallinnan tarkoitus on pitää ohjat tiukasti käsissä ja samalla se saa aikaan seuraavat seikat:
- yhtään muutosta ei tehdä ilman kaikkien osapuolien yhteistä sopimusta
- harkitsemattomat muutokset jäävät tekemättä
Muutosten teon hallinta
Tehdystä muutoksesta on dokumentoitava mm. mihin muutospyyntöön se liittyy ja mitä dokumentteja ja ohjelmia on muutettu.
Muutosta ei saa hyväksyä versiohallinnan suojattuihin kirjastoihin ennenkuin
- muutos on testattu yksilöllisesti,
- muutoksen ympäristö on testattu,
- taantumatestauksen sopiva osa on suoritettu ja
- muutoksen vaikutuspiirissä oleviin dokumentteihin tulevat muutokset on tarkastettu
Versiohallinta
Yleistä
Versiohallinnalla pyritään estämään ongelmia, jotka syntyvät esimerkiksi seuraavista syistä:
- kaksi ohjelmoijaa päivittää samaa ohjelmaa yhtäaikaa => toisen tekemät muutokset häviävät
- yhteiskäyttöisen moduulin muuttaminen => ei muisteta ilmoittaa kaikille muutoksesta
- korjaus tehdään saman ohjelman yhteen versioon, mutta ei kaikkiin
- korjaus tehdään, mutta sitä ei dokumentoida (esim. kiireen takia)
- ohjelmaa ei testata muutoksen jälkeen kunnolla, jolloin muutoksen haitalliset sivuvaikutukset jäävät huomaamatta
- ohjelmistokokonaisuus, josta voidaan koota erilaisia lopputuotteita, kootaan vääristä palasista
- asiakkaalla olevasta ohjelmasta ei pystytä sanomaan, mikä versio se on
Standardit asettavat tiukkoja vaatimuksia versiohallinnalle.
Perusratkaisu
Kirjastorakenne ja säännöt kirjastojen käsittelystä:
Kuva 1. Kirjastorakenne
Muutokset versioihin tehdään työtiloissa. Versiot työtiloihin haetaan useimmiten kehityskirjastosta, mutta mahdollisesti myös muista kirjastoista. Muutokset palautetaan aina kehityskirjastoon ja muutosten yhteydessä monipäivitys estetään.
Kehityskirjastosta versiot siirretään jäätyvään kirjastoon. Jäätyvään kirjastoon saa vain lisätä uusia versioita ja korvata muuttuneita versioita. Jäätyvästä kirjastosta voi olla monta versiota.
Jäätyvästä kirjastosta versiot siirretään jäädytettyyn kirjastoon. Jäädytetyssä kirjastossa olevia versioita ei saa koskaan muuttaa.
Asiakasversio muodostetaan jäädytetyssä kirjastossa olevasta versiosta valitsemalla käytetty sovitus ja tekemällä mahdolliset asiakaskohtaisten parametrien asetukset. Asiakasversiossa ei yleensä ole lähdekielisiä ohjelmia eikä suunnitelmia yms. työskentelydokumentteja.
Perustoiminnot
- Yksittäisten tiedostojen versioitumisen hallinta
- versioitumissyiden kirjaaminen
- rinnakkaisen (ts. samanaikaisen) muuttamisen hallinta
- maantieteellisen hajautuksen hallinta
- Yhtenäisten työtilojen hallinta
- työtilojen luominen ja muutosten palauttaminen muiden käytettäväksi
- yhteenkuuluvien rakenneosien luetteloiminen
- tarvittavien rakenneosien, testimateriaalien, apuvälineiden yms. säilyttäminen
- Lopputuotteiden kokoonpanon hallinta
- kuhunkin versioon kuuluvien rakenneosien luetteloiminen
- järjestelmän eri versioiden kokoaminen rakenneosistaan
- Laaduntarkkailu
- kirjastoihin tarjottujen ohjelmien ja dokumenttien laadun tarkastaminen
- laadun kehittymisen seuraaminen
- Kirjastojen hallinta
- suojattujen kirjastojen ylläpito
- ohjelmiston eri rakenneosien ja niihin liittyvien dokumenttien eri versioiden valmiusasteen ja muutosten kirjaaminen
- asiakkaille toimitettujen järjestelmien versiotietojen kirjaaminen
- kopioiden antaminen kirjastojen sisältämistä tiedostoista
- muutoshistorioiden kopioiden luovuttaminen
- ohjelmistopakettien eri versioiden luovuttaminen käytettäväksi muissa ohjelmistoissa
- vanhentuneiden tiedostojen poistaminen
- Prosessin hallinta
- työskentelymenettelyjen noudattamisesta huolehtiminen
- yhteys muutostenhallintaan
Perustoimintojen suorittamiseksi pitäisi olla automaattiset välineet.
Versiohallinnan tulee taata, että aina voidaan vastata seuraaviin kysymyksiin:
- mikä versio tämä on
- mistä osista se koostuu
- mitkä ovat sen määritykset
- mikä on muuttunut edelliseen versioon nähden
- mitkä testit sille on suoritettu
- mitkä olivat testien tulokset
- missä on lähdekielinen koodi
Peruskäsitteitä
Tuoteperusta (baseline) on muodollisesti hyväksytty ja kiinnitetty informaatiojoukko, joka määrittelee järjestelmän. Tuoteperustalla on tyypillisesti jokin nimi (esim. "1.1.5"). Tuoteperusta kasvaa ohjelmiston (asianomaisen tuoteversion) kehityksen edetessä. Kussakin vaiheessa syntyneet dokumentit ja ohjelmat viedään versiohallintaan tuoteperustana ja seuraavan vaiheen työskentely perustuu tähän tuoteperustaan.
Tuoteversio (release) on valmis, tietyn tuoteperustan mukainen lähdekielinen järjestelmä. Järjestelmän kehittyessä siitä tehdään uusia tuoteversioita, joissa on aiempiin nähden tyypillisesti seuraavanlaisia muutoksia:
- virheitä on korjattu
- toimintaa on tehostettu
- uusia piirteitä on lisätty
- järjestelmä on muutettu ympäristön muuttumista vastaavasti
Sovitus (version, variant) on tietystä tuoteversiosta ("perussovitus") tiettyyn tarkoitukseen tehty sovitus. Sovituksia voidaan tehdä esimerkiksi
- eri asiakkaita varten
- eri laiteympäristöjä varten
- apuohjelmistojen (esim. tietokantajärjestelmä) eri versioita varten
Sovitus voidaan toteuttaa teknisessä mielessä
- ottamalla mukaan vs. jättämällä pois kokonaisia moduuleita
- ottamalla mukaan joku vaihtoehtoisista moduuleista
- tekemällä moduulin sisällä olevia muutoksia yhteen tai useampaan moduuliin
Eri sovitusten yhteiset osat tulee olla vain yhdessä paikassa.
Toimitusversio on valmis suorituskelpoinen järjestelmä, josta on tiedettävä
- mistä tuoteversiosta se on tehty
- mistä sovituksesta se on tehty
- mitä apuohjelmistojen versioita on käytetty
Edelläkuvatut tiedot on oltava toimitusversion mukana (esimerkiksi omana tiedostonaan) ja ne on muodostettava automaattisesti. Niiden perusteella pitää voida muodostaa toimitusversio tarvittaessa uudelleen.
Asiakasversio on asiakkaalla oleva toimitusversion kopio, johon on tehty asiakaskohtaisien parametrien asetukset ja jota asiakas on voinut muuttaa asentamisen jälkeen.
Versio on yleistermi, joka voi tarkoittaa mitä tahansa edellisistä.
Paikka (patch) on yksittäiseen komponenttiin kohdistuva korjaus, josta on tiedettävä
- paikan oma tunniste
- mihin tuoteversioon se liittyy
- mihin sovitukseen se mahdollisesti liittyy
- mitä apuohjelmistojen versioita on käytetty
Asiakaspaikka on asiakasversioon viety paikka.
Työtilan toteutustapoja
- Holvi
Työtila luodaan hakemalla kaikista tarvittavista tiedostoista asiaankuuluvat versiot keskitetystä tiedostovarastosta yksi kerrallaan (check-out). Ohjelmoija tekee muutokset omassa työtilassaan. Muutetut tiedostot palautetaan varastoon yksi kerrallaan (check-in). Seurauksia:- toiseen työtilaan siirtyminen on iso toimenpide
- samasta tiedostoversiosta on liikkeellä useita kopioita
- Suorakäyttöinen varasto
API, jonka kautta oikean version saa haettua. Ohjelmoija määrittelee kulloinkin käyttämänsä työtilan. Seurauksia:- kaikkien apuvälineiden on käytettävä API:a
- Näennäistiedostojärjestelmä
Pääsy tiedostojärjestelmään tapahtuu erityisten ajureiden kautta, jotka hakevat todellisesta tiedostojärjestelmästä asiaankuuluvat versiot. Ohjelmoija määrittelee kulloinkin käyttämänsä työtilan kuten edellä. Seurauksia:- toiseen työtilaan siirtyminen on helppoa
- versiohallinnan tarvitsemat hakemistot ja tiedostot eivät näy ohjelmoijalle millään tavalla
- apuvälineiden normaaliversiot kelpaavat
Työtilan määrittelytapoja
- Rajoittamaton
Ohjelmoija valitsee työtilaansa tulevat tiedostot yksitellen oman halunsa mukaisesti. Seurauksia:- altis virheille
- Hierarkkinen
Työtilaksi saadaan koko (tietyn - mahdollisesti väliaikaisen - tuoteperustan mukainen) tilanne. Muutokset tehdään työtilassa ja palautetaan kerralla kehityskirjastoon. Seurauksia:- toisen ohjelmoijan (omassa työtilassaan) tekemien muutosten siirto toisen ohjelmoijan työtilaan on hankalaa
- Muutosjoukot
Muutosjoukko on samaan muutokseen liittyvien tiedostoversioiden joukko. Työtilaksi saadaan koko tietynhetkinen tilanne lisättynä halutuilla muutosjoukoilla. Muutosjoukot voivat kumuloitua ja yleensä ne viedään jossain vaiheessa tuoteperustaan. Seurauksia:- edellyttää järjestelmältä kykyä yhdistää erillisinä tehdyt, samoihin tiedostoihin liittyvät muutokset
- Sääntöpohjaisuus
Kustakin tiedostosta valitaan oikea versio kyselykielen avulla.- staattinen: käytettävät versiot määräytyvät työtilan muodostamisvaiheessa
- dynaaminen: käytettävät versiot määräytyvät tiedostoja käytettäessä
Työtilan hallintaa tarvitaan, koska on pystyttävä vaikuttamaan siihen, miten ohjelmoija näkee muiden muutokset ja miten muut näkevät hänen muutoksensa.
Yksinkertaisia apuvälineitä
- Tiedostohistorian hallintaan:
- Subversion
- CVS
- PVCS
- RCS
- Rinnakkaisen kehittämisen hallintaan:
- RCS:n ja vastaavien haarautumiskäsite ja haarojen yhdistäminen
- ClearCase:n vastaava käsite
- Sovitusten hallintaan:
- RCS:n ja vastaavien haarautumiskäsite (mutta haaroja ei voi nyt yhdistää). Yhteiset osat ovat useana kopiona => ylläpito on vaikeaa.
- Erotiedosto (delta), jossa perussovituksen tiedoston lisäksi muodostetaan erotiedosto, jonka avulla saadaan sovituksessa tarvittava tiedosto. Menetelmä on hankala, jos sovituksia on paljon ja erotiedostot "ketjuuntuvat" sovellettavaksi toinen toisensa jälkeen.
- Ehdollinen käännös (conditional compilation), jossa yhdestä tiedostosta saadaan kussakin sovituksessa tarvittava tiedosto ottamalla vain osa riveistä mukaan.
- Muunnosohjelmistot, joiden avulla perussovituksen tiedostosta saadaan automaattisesti muun sovituksen tiedosto.
- Sovituskohtaiset hakemistot, jossa sovituskohtaisia osia sisältävät tiedostot säilytetään sovituskohtaisissa hakemistoissa.
- Kokoonpanon hallintaan:
- Tekotiedostot (makefiles), joiden avulla sovituksen rakentaminen automatisoidaan.Ne voivat käyttää hyväksi esim. erotiedostoja, ehdollista käännöstä, muunnosohjelmistoja ja sovituskohtaisia hakemistoja.
- Tuoteversioiden hallintaan:
- RCS ja vastaavat
- Versiomuutosten tarkastamiseen:
- Taantumatestaus
- Tuoteversioiden ja sovitusten tunnistamiseen:
- Tuoteversio- ja sovitustiedon sijoittaminen käännettyyn ohjelmakoodiin
Uuden tuoteversion muodostaminen
Jäädytys tehdään automaattisilla välineillä. Ennen jäädytystä tehtävä ainakin:
- varmistettava, että tuoteversionumero on kaikkialla muutettu
- varmistettava, että testauksen tarvitsemat koodinpätkät on poistettu
- testaus, jolla varmistetaan, että kaikki muutokset ovat mukana
- dokumentoinnin tarkastus, jolla varmistetaan, että kaikki muutokset näkyvät myös dokumenteissa
- taantumatestaus
- asennustestaus eri ympäristöihin
- virustarkastus
Vain jäsenille: