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 Luentojen jälkeen opiskelijan tulisi osata: 2
Sisällöstä Tavoitekalvon asioita. 3
Motivointia 4
Ohjelmistotuotteenhallinnan perusteet Tuotteenhallinta eli configuration management. Sisältää ne komponentit ja osaset, joista kokonaisuus koostuu. Ohjelmistotuotteenhallintaan kuuluu: muutoksen tai muutostarpeen tunnistaminen muutoksen kontrollointi (hallinta) varmistetaan, että muutos toteutetaan kelvollisesti raportoidaan muutoksesta niille, jotka siitä ovat kiinnostuneita 5
Tuotteenhallinta antaa menetelmiä komponentin eri versioiden hallintaan, konfiguraatioiden eri versioiden hallintaan, versioiden ja konfiguraatioiden luomiseen ja muuttamiseen. 6
Tuotteenhallinta vs. kehitysprosessi Kehitysprosessissa: työskentelyn ja koordinoinnin tueksi. Halutaan mm. välttää: ettei kehitetty ja testattu piirre katoa korjattu virhe tule takaisin ym 7
Ylläpidossa: mihin aiotut muutokset vaikuttavat tietyn asiakkaan konfiguraatio komponettien eri versioiden yhteensopivuus tietyn asiakkaan ohjelmiston uudelleen rakentaminen (kuinka) 8
Peruskäsitteet komponentit (esim. tiedostot) konfiguraatio (kasa komponentteja tai konfiguraatioita) hallinta-alkio (konf. tai komponentti) johdetut komponentit (automaattisesti saatavia, esim. kääntämiseen liittyviä) versio (jäädytetty hallinta-alkio, lukitus) vaihetaso (baseline, hallinta-alkion viimeisin jäädytetty version) ulkoiset tuotejulkistukset sisäiset julkistukset mm. testausta varten Jäljitettävyys, ohj. komponenttien versioiden tunnistaminen ohjelmaversion perusteella. 9
Versionhallinta Peräkkäiset versiot, revisiot. Sivuhaarat, eli variaatiot. Versioiden numerointi. (Ei vak.) 1.1 2.1 3.1 1.2 2.2 3.2.1 3.2.2 3.2.3 1.3 3.3 1.4 1.5 10
Ohjelmiston muutoksista, muuttumisesta Muutospyynnöt ja muutosmenettely. Muutoskategorioina voivat toimia: kriittiset virheet bugit ja muut ongelmat (jotka eivät yhtä vakavia kuin yllä) parannusmuutokset uudistuneiden vaatimusten tuoma muutostarve muut muutostarpeet (esim. otetaan käyttöön jotain kaupallisia komponetteja omien vanhojen tilalle) 11
Hallinta-alkioiden kaipaamaa dataa: versionumero tekijä (omistaja) tila (esim. ei aloitettu, tekeillä, valmis) testitapaukset ja testiympäristöt versionumeroineen (ehkä) käytetyt työkalut ja niiden versiot (ehkä) ym. 12
Alun menetelmät uudestaan komponentin eri versioiden hallinta Mitä versioita on olemassa? Mistä/miten vanhat löytyvät? Mikä komponentti kyseessä? Ominaisuudet. Voiko tehdä samanaikaisia muutoksia? 13
konfiguraatioiden eri versioiden hallinta Mitä versioita on olemassa? Mistä/miten vanhat löytyvät? Mikä konfiguraatio kyseessä? Mitä komponetteja asiakkaan järjestelmän versiossa? Miten asiakkaan tietty versio rakennetaan? Mihin kaikkialle tiettyyn komponettiin tehdyt muutokset vaikuttavat? 14
versioiden ja konfiguraatioiden luominen Vastuut ja toimintavaltuudet Miten vaihetuotteet siirtyvät vaiheesta toiseen? Miten uudet versiot hyväksytään ja julkistetaan? Miten muutosesitykset ja virheraportit tehdään ja käsitellään? Miten arkistointi ja varmistuskopiointi hoidetaan? 15
Miksi on eri konfiguraatioita? tuoteversiot laiteympäristöt hieman erilaisia vaatimuksia asettavat asiakkaat tuotteen myyntistrategiat Jos asiakas raportoi ongelmasta, pitää pystyä vastaava konfiguraatio rakennettua, jotta ongelmaa pystyy analysoimaan. 16
Tukea yhtäaikaiselle työlle Rakennetaan säännöllisesti ja usein uusi versio (usein päivittäin). Esim. Organisaatiossa toimitusaika (esim. 14:00) komponenteille. Uusi versio rakennetaan komponenteista kääntämällä koko systeemi uusiksi. Uusi versio toimitetaan testausryhmälle, jotka testaavat ennalta suunnitellulla tavalla uuden version. Kehittäjät kehittävät samaan aikaan komponentteja normaalisti. Testausryhmä dokumentoi ongelmat ja myös kertovat niistä kehittäjille, jotka korjaavat nuo ongelmat seuraavaan versioon. 17
Säännöllisten uusien versioiden etuja: Komponenttien välisissä yhteyksissä olevien ongelmien aikainen havaitseminen. Kehittäjillä on paineita olla rikkomatta versiota. Tällainen lähestyminen vaatii tiukan muutostenhallintaprosessin, joka seuraa ongelmia niiden löytymisestä korjauksiin. Lisäksi eri versioita tulee hyvin paljon, mikä osaltaan asettaa vaatimuksia muutostenhallintaprosessille ja sen tueksi hankituille työkaluille. 18
Tuotteenhallinnan suunnittelu Voi olla osana projektisuunnitelmaa laatusuunnitelmaa tai sitten voi olla oma dokumenttinsa. Suunnitelmia voidaan rakentaa osana laatujärjestelmää tai projekti- tai tuotekohtaisesti. Tuotteenhallinnan suunnitelman esimerkkisisällysluettelo löytyy mm. Haikalan ja Märijärven kirjasta. Ylläpitoprosessi? 19
Järjestelmiä: CVS RCS PVCS CC SCCS 20