Avoimen lähdekoodin ohjelmien ylläpito ja evoluutio

Transkriptio

1 Avoimen lähdekoodin ohjelmien ylläpito ja evoluutio Terminologiaa Avoimen lähdekoodin yhteisöt Projektimalleja Puutteiden käsittely (muutospyynnöt) Projektityypit ja projektien evoluutio Evoluutiomallit ja Lehmanin lait Arkkitehtuurin rooli 1 Terminologiaa Avoin lähdekoodi (open source) lähdekoodi käyttäjän saatavilla Vapaa ohjelmisto (free software) vapaus ajaa ohjelmaa vapaus tutkia ja mukauttaa ohjelmaa vapaus levittää ohjelmaa vapaus parantaa ohjelmaa Vapaa ei välttämättä tarkoita ilmaista 2

2 Avoimen lähdekoodin yhteisö Projektin johtaja Ydinjäsenet Aktiiviset kehittäjät Satunnaiset kehittäjät Virhekorjaajat j Virheraportoijat Lukijat Passiiviset käyttäjät 3 Yhteisömalleja Verkostorakenne Hierarkkinen rakenne Johtaja 4

3 Kehitysmalleja Katedraalimalli kehittäjät toteuttavat järjestelmiä johtajan suunnitelman pohjalta muistuttaa tavanomaista ohjelmistokehitystä Basaarimalli kehittäminen ja suunnittelu vapaata, ja jokainen voi osallistua muutosten suunnitteluun järjestelmät eivät perustu tarkkoihin suunnitelmiin 5 Prosessin toteuttaminen Ylläpitoprosessi (ISO/IEC) Ongelman ja muutoksen analysointi Muutoksen tarkistaminen/ hyväksyntä Muutoksen toteuttaminen Korvaaminen Siirtyminen 6

4 OSS-ylläpitoprosessi Käyttäjä 1. Raportoi 2. Noutaa Analysoi 3. Noutaa Muuttaa 5. Päivittää 4. Päivittää 6. Näkee Noutaa DMS Defect management system Version management system VMS 7 OSS-ylläpitoprosessi 1. Käyttäjä raportoi virheestä puutetietokantaan 2. noutaa virheilmoituksen, varmistaa virheen olemassa olon ja analysoi sitä 3. Toteutusvaihe: käyttäjä noutaa lähdekoodin, korjaa virheen ja lisää muutoksen versionhallintajärjestelmään 4. Muutos tarkistetaan ennen kuin se hyväksytään ja lähdekoodi laitetaan versionhallintajärjestelmään 5. Tilanne päivitetään puutetietokantaan 6. Uusi versio on saatavilla versionhallintajärjestelmästä tai webistä 8

5 Muutosten jaottelu Standardin mukainen jaottelu ehkäisevä korjaava täydellistävä mukauttava OSS-jaottelu korjaukset lisäykset puutteet (bugit, virheet, ym.) lisäykset 9 Puutteiden luokittelu Muutospyyntö Puuteraportti Ilmoitus Raportointi Vaatii muutosta Koodin muuttaminen Ei vaadi muutosta Analysointi Toteutus/ Ratkaisu Korjattu puute Kaksoispuute Epäkelpo puute Muu puute Tarkistus Suljettu 10

6 Puutteiden luokittelu Tyyppi Alityyppi Selitys Lisäys Uuden ominaisuuden pyytäminen Puute Estävä Estää uuden julkistuksen Kriittinen Estää käytön Suuri Estää joidenkin oleellisten toimintojen käytön Normaali Oleellisimmat toiminnot käytettävissä Pieni Ei estä käyttöä Ti Triviaalii Kosmeettinen tai muu käyttöliittymän ä ongelma Tukipyyntö Help desk tyyppinen pyyntö Korjaustiedosto (patch) Käyttäjät voivat lähettää parannuksia puutetietokannan kautta 11 Puuteraportin tiedot Tieto Tunniste (id) Ympäristö Status Ratkaisu Vastuuhenkilö Vakavuus Raportoija Yhteenveto Luokittelu Toimintaloki Kuvaus Tunnistenumero Ohjelmisto ja sen ympäristö, jossa puute ilmenee (esim. tuote, komponentti, versio, alusta) Puutteen nykyinen tilanne (esim. korjattu, uusi) Miten puute on ratkaistu, vaatiko korjausta vai ei? Kuka hoitaa korjaamisen? Kuinka vakava puute on? Kuka raportoi virheestä? Puutteen kuvaus Vika, lisäys, jne. Mitä muutoksia puuteraporttiin on tehty? 12

7 OSS-evoluutio Hakemisto F1 Hakemisto F2 Vertikaalinen kasvu F1 F2 F3 Hakemisto F1 F2 F3 Horisontaalinen kasvu 13 GNU Wingnut korjaustiedosto korjaustiedosto Evoluutiomalleja palaute palaute PostgreSQL Jun Linux liitetään julkaistut versiot korjaustiedosto testiversiot korjaustiedosto liitetään 14

8 Projektityypit ja evoluutio Tutkimus Hyöty Palvelu Tavoite Innovaatioiden ja tietämyksen Yksilöllisen tarpeen Vakaiden palveluiden jakaminen tyydyttäminen tuottaminen Kontrolli Katedraali Basaari Neuvosto Evoluutiomalli Yksihaarainen; yhteisön palaute Useita versioita; paras voittaa Yksihaarainen; korjaustiedostojen yhdistäminen Yhteisön rakenne Projektin johtaja Paljon lukijoita Paljon satunnaisia Ydinjäsenet Paljon passiivisia kehittäjiä käyttäjiä Suurimmat ongelmat Esimerkkejä Jakaantumisvaara GNU-järjestelmät Jun, Perl Oikean ohjelman valitseminen Linux kerneliä lukuunottamatta Innovaatioiden puute PostgreSQL Apache 15 Projektien evoluutio Tutkimus Olemassa olevat järjestelmät Siemen Uusi idea Tutkimus Kypsyminen Palvelu Kypsyminen Palvelu Höt Hyöty Uudet tarpeet Höt Hyöty Nopea evoluutio Hidas evoluutio Nopea evoluutio Hidas evoluutio 16

9 Lehmanin lait OSSevoluutiossa Lehmanin lait on alun perin kehitetty suljetun lähdekoodin ohjelmille Miten lait pätevät avoimen lähdekoodin ohjelmille? riippuu tarkasteltavista ohjelmista Seuraavilla kalvoilla esitettyjä tuloksia ei pidä yleistää 17 Lehmanin lait (I-IV) 1. Jatkuva muutos laki pitää paikkansa, erityisesti kypsyneeseen tilaan päässeillä projekteilla 2. Lisääntyvä monimutkaisuus vaikea tunnistaa niitä muutoksia, joiden on tarkoitus vähentää monimutkaisuutta tulokset ristiriitaisia 3. Itseohjautuvuus / suurten järjestelmien evoluutio ei selvyyttä paikkansa pitävyydestä 4. Organisaation vakaus työtahdille vaikea löytää mittareita kehittäjien määrä kasvaa järjestelmän elinajan kasvaessa ei tarpeeksi dataa, jotta voitaisiin päätellä lain paikkansa pitävyyttä 18

10 Lehmanin lait (V-VIII) 5. Julkistusversioiden vakaus moduulien kasvaminen sattumanvaraista laki ei pidä paikkaansa 6. Jatkuva kasvu laki pitää paikkansa 7. Heikkenevä laatu vaikea mitata, koska ei tarkat määrittelydokumentit puuttuvat 8. Vuorovaikutteisuus/palaute vakaa kasvunopeus, ei vaihtele palautteen mukaan palaute luonteeltaan erilaista kuin suljetun lähdekoodin ohjelmissa 19 Arkkitehtuurin rooli Joukko sääntöjä, jotka ohjaavat muutosten tekemistä koodiin Abstraktio, joka helpottaa järjestelmän ymmärtämistä Arkkitehtuurin laadun analysointi tapahtuu keskustelujen kautta, ei eksplisiittisiä menetelmiä Modulaarisuus tärkein laatuvaatimus muita: muutettavuus, laajennettavuus, integroitavuus Arkkitehtuuri dokumentoidaan aluksi, mutta myöhemmin dokumentit eivät yleensä ajan tasalla 20

11 Miksi OSS-arkkitehtuuri on hyvä? Vertaistarkistukset tarkistuksissa tarkistetaan myös, että koodi noudattaa arkkitehtuuria Vertaistuki riittävän suuri määrä kehittäjiä -> todennäköisesti ainakin joku osaa ratkaista ongelman Demokratia suuren asiantuntijajoukon keskimääräinen mielipide on luotettavampi kuin yksittäisen asiantuntijan mielipide Taitavat ja motivoituneet kehittäjät 21 Miksi OSS-arkkitehtuuri on huono? Osallistumisen ja/tai demokratian puute ei tarpeeksi osallistujia Dokumenttien puute voi haitata arkkitehtuurin päätösten ja perusteluiden ymmärtämistä 22