Ohjelmistotekniikka - Luento 5

Ohjelmistotekniikka - Luento 5 Luku 22: Ohjelmistotuotteen hallinta (SCM) - alkio, komponentti, versio, vaihetaso ja kuvauskanta - SCM prosessi - muutosten valvonta - julkistusten hallinta Luku 23: Tuotemetriikat - mittaamisesta - toimintopistemetriikka - oliosunnittelun metriikat (QMOOD)!1

22: Ohjelmistotuotteen hallinta Muutosten hallinta (change management) ja ohjelmistotuotteen hallinta (software configuration management) ovat sateenvarjo-aktiviteetteja, joita tarvitaan ja tehdään koko ohjelmistokehitysprosessin ajan.!2

Muutokset ovat väistämättömiä muuttuneet vaatimukset aiheutuvat -muutoksista liiketoiminnassa -muutoksista käyttäjän tarpeissa -uudelleenorganisoinnista tai liiketoiminnan kasvusta/vähenemisestä -muutoksista budjetissa tai aikataulussa suunnittelutason kuvauksiin aiheuttavat muutoksia dataan testitapauksiin Projektisuunnitelmaan koodiin!3

Tuotekehitys- / asiakasnäkökulma Tuotekehitysprosessin kannalta keskeisin tavoite on antaa tuotekehitystiimille stabiili ja kontrolloitavissa oleva ympäristö => versionhallinta, pelisäännöt, työskentely-ympäristö, testiversioiden rakentaminen. Asiakasprosessin (toimitusten) kannalta keskeisin tavoite on asiakastoimitusten konfiguraatioiden hallinta: mitä tarkkaanottaen asiakkaalle toimitetaan / on toimitettu miten toimitettava kokonaisuus kootaan ja paketoidaan Haikala (luentomateriaali) 2005!4

Tuotteenhallinnan ongelmia Ongelma asiakkaalla X, tuote Y, versio a.b.c On pystyttävä rakentamaan versio a.b.c (konfiguraation versio, komponenttien versiot). Kun korjaus on suunniteltu ja tehty, syntyy muutettujen komponenttiversioiden uudet versiot ja tuotteen uusi versio. On vielä aikamoinen urakka selvittää Missä muissa korjattujen komponenttien versioissa esiintyy sama virhe. Johtaako virheen korjaus muutoksiin virheellistä komponenttia hyödyntäneissä komponenteissa. Haikala (luentomateriaali) 2005!5

Hallinta-alkio 0..* 0..* Komponentti Konfiguraatio on versio 1 Versio 0..* 1 on versio 0..* 0..* 0..* Komponentin versio Konfiguraation versio Komponentti voi olla myös johdettu, esim. käännetty toisesta komponentista -> myös kääntäjä tuotteenhallinnan piiriin Versio on jäädytetty hallinta-alkio Haikala (luentomateriaali) 2005!6

Vaihetasot (baselines) IEEE Std. No. 610.12-1990 määrittelee vaihetason: A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Määrittely tai tuote, joka on katselmoitu ja hyväksytty ja siten toimii tulevan kehityksen perustana ja johon voidaan tehdä muutoksia ainoastaan formaalin muutostenhallintaprosessin kautta.!7

Komponentti A 1.0 1.1 Komponentti B Komponentti C Komponentti D 1.0 1.0 1.0 1.1 1.1 1.1 Vaihetasoja syntyy jokaisesta hallintaalkiosta (konfiguraatiosta ja komponentista) 1.2 1.2 1.2 Vaihetasot (baseline) 1.3 1.3 release = julkistus, julkaisu (asiakkaalle toimitettava) build = mikä tahansa suoritettava vaihetaso merkkaus (tagging) = julkaisuun liittyvien versioiden merkkaus versionhallintatyökalussa Haikala (luentomateriaali) 2005!8

Vaihetasot (baselines) / Pressman 2005!9

Mistä ohjelmistotuote/ konfiguraatio koostuu? Pressman 2005!10

SCM kuvauskanta (tietovarasto) SCM kuvauskanta sisältää hallinta-alkioiden lisäksi tiedot komponenttien käyttäjistä, järjestelmän asiakkaista, käytettävistä alustoista (platform), esitetyistä muutoksista Sen avulla tulisi mahdollistaa kyselyt Mille asiakkaille tiettyä versiota on toimitettu? Mikä laitteisto ja käyttöjärjestelmä vaaditaan tietyn version suorittamisessa? Kuinka monta versiota tietystä järjestelmästä on olemassa ja milloin ne on luotu? Mihin versioihin tietyn komponentin muutos vaikuttaa? Kuinka monta muutospyyntöä on tehty tiettyyn versioon? Kuinka paljon vikoja on raportoitu tietystä versiosta?!11

Kuvauskannan ominaisuudet Versiointi. saves all of these versions to enable effective management of product releases and to permit developers to go back to previous versions Riippuvuuksien jäljitys ja muutosten hallinta. The repository manages a wide variety of relationships among the data elements stored in it. Jäljitys vaatimuksiin. Provides the ability to track all the design and construction components and deliverables that result from a specific requirement specification Konfiguraation hallinta. Keeps track of a series of configurations representing specific project milestones or production releases. Version management provides the needed versions, and link management keeps track of interdependencies. Jäljitysketju (audit trails). establishes additional information about when, why, and by whom changes are made. Pressman 2005!12

Miten muutosten hallinta hoidetaan? Ohjelmistotuotteen hallinta (SCM, Software Configuration Management) aktiviteetit ovat: Tunnista muutos Ohjaa muutoksen suoritusta Varmista, että muutos on toteutettu oikein Ilmoita muutoksesta muille siitä kiinnostuneille raportointi tuotteenhallinta muutoksenhallinta versionhallinta tunnistus Ohjelmisto V m.n hallintaalkiot (SCIs) Pressman 2005!13

Perinteisesti (keskitetyssä) versionhallinnassa talletus tapahtuu muutoksen (delta) tallentamisella delta = muutos kahden hallinta-alkion version välillä forward delta periaate = talletetaan ensimmäinen versio kokonaan ja jatkossa vain tehdyt muutokset reverse delta periaate = talletetaan viimeisin versio ja peruutuksen tarvitsemat muutokset 1.3.1.0 1.3.1.1 1.3.1.2 variaatio revisio 1.3 1.4 1.5 1.6 1.3.2.0 1.3.2.1 Monihaarainen versiopuu - voi vaikeuttaa komponentin ylläpitoa Versionumerointi vaihtelee, mutta voi olla esim. 1-4 numeroinen (1 1.1.1.1), jossa 1 taso on jos on tehty uudelleen suurimmalta osalta 2 taso kertoo jos on tehty toiminnallisia muutoksia 3 taso kertoo virheiden korjaamisesta (4 taso on tuotekehityksen välitallennuksia varten)!14

Versiot ja haaroittuminen Haara Runko Erikoistumishaarautuminen - tietyn asiakkaan tarpeisiin - ei yhdistetä runkoon Haara Liitos Haara Runko Kehityksen haarautuminen - kehittäjä(t) kehittävät jonkin aikaa osaa järjestelmästä - oma hiekkalaatikko - muiden tekemät muutokset ei näy - liitetään myöhemmin runkoon V 1 V 2 Runko V 3 Monia versioita: Erikoistumishaarautuminen - ongelmana esim. virheiden korjaus - voidaan joutua etsimään ja korjaamaan virhe useista versioista V 3a Shalloway et al. 2011!15

Versiot ja haaroittuminen Liitos 1 A 2 A 1 B 1 B2 Liitos 2 Liitos 3 Runko Liitos 4 Työskentely eristyksissä: Kehityksen haarautuminen - haarautumisella kapseloidaan oma työ - ongelmana liitosten (yhdistämisien) kustannukset Liitoskustannus Kompleksisuus Liitoskustannus Liitosten kompleksisuus Liitosten välinen aika Liitosten välinen aika Shalloway et al. 2011!16

Versiot ja haaroittuminen Liitos 1 Runko uusi A 1 B 1 Runko vanha Jos toisen tiimin tekemiä muutoksia ei heti liitetä uuteen haaraan, joudutaan yhdistäminen tekemään myöhemmin. Liitos 2 Liitos 1 Runko A 1 B 1 Liitos uudestaan Liitos 2 Liitos uudestaan (merge-back) - liitetään runkoon tehdyt muutokset välittömästi myös uuteen haaraan Shalloway et al. 2011!17

Versiot ja haaroittuminen A B Liitos Verifioi liitos Liitos uudestaan Verifioi liitosuudes taan Kustannuksiin vaikuttavat tekijät Shalloway et al. 2011!18

kokonaiskustannukset Versiot ja haaroittuminen verifiointi Kustannukset liitos Liitosten välinen aika Kun käytetään perinteistä testausta Kustannukset kokonaiskustannukset verifiointi liitos Liitosten välinen aika Kun käytetään TDD (test-driven development) menetelmää Shalloway et al. 2011!19

Keskitetty versionhallinta Perinteiset versionhallintajärjestelmät ovat lähes yksinomaan keskitettyjä. ainoa kopio versiotietokannasta sijaitsee palvelimella kaikki kehittäjien tekemät muutokset versionhallintaan tehdään verkkoyhteyden yli yhteiseen jaettuun versiotietokantaan. Yleisimpiä käytössä olevia keskitettyjä versionhallintajärjestelmiä ovat Subversion, CVS ja ClearCase!20

Hajautettu versionhallinta Hajautetut versionhallintajärjestelmät eivät edellytä keskitettyä tietokantaa. Jokaisella kehittäjällä on oma, täydellinen kopio versiotietokannasta -> nopeuttaa kehitystä. Vaikka kopiotietokannat ovat teknisesti tasa-arvoisia, käytännössä usein tiettyä, palvelimella ylläpidettävää kopiota kohdellaan "virallisena kaikki kehittäjät lopulta integroivat muutoksensa siihen projektin julkaisut tehdään siitä Yleisimmät hajautetut versionhallintajärjestelmät ovat Git ja Mercurial.!21

Git hajautettu versionhallinta Git tukee haaroittumista, oma hiekkalaatikko jokaiselle kehittäjälle. kehittäjä voi käyttää lyhytaikaisia haaroja kokeiluun Git ylläpitää muutoskokonaisuuksien sisällöstä ja "sukupuusta" kirjaa kahden kehittäjän erikseen tekemät samanlaiset muutokset pystytään todentamaan identtisiksi säästytään monilta konflikteilta siinä vaiheessa kun kehittäjät synkronoivat omaa versiohistoriaansa projektin keskitettyyn versiotietokantaan.!22

Versionhallinta jatkuvan integroinnin (continuous integration) tukena Kaikki kehittäjät suorittavat itsenäisesti integroinnin omilla työasemillaan ennen ohjelmakoodimuutosten siirtämistä versionhallintaan, jotta he varmistuvat siitä etteivät heidän tekemänsä muutokset riko integrointia. Kehittäjät siirtävät muutoksensa versionhallintaan vähintään kerran päivässä. Integrointi tapahtuu erillisellä palvelimella useita kertoja päivässä. Kaikkien automaattisten testien on mentävä läpi jokaisessa onnistuneessa integroinnissa. Integroinnin tuloksena syntyy tuote, jonka toiminnallisuutta voidaan testata manuaalisesti. Epäonnistuneen integroinnin korjaaminen (fixing broken build) on aina korkeimman prioriteetin tehtävä. Jotkut kehittäjät seuraavat jatkuvan integroinnin generoimia raportteja etsiäkseen parantamisen kohteita. Tällaisia seurattavia asioita ovat esimerkiksi ohjelmointistandardit ja riippuvuusanalyysit.!23

22 (loppuosa). Muutosten valvonta STOP!24

Muutosten valvontaprosessi Pyydetään muutosta täyttämällä Muutospyyntölomake Analysoidaan pyyntö Jos pyyntö on aiheellinen, niin arvioidaan, miten muutos toteutetaan arvioidaan muutoskustannukset tallennetaan pyyntö tietokantaan toimitetaan pyyntö muutosten hallintaryhmälle jos muutos on hyväksytty, niin toistetaan tee muutokset ohjelmistoon tallenna muutokset ja linkitä muutospyyntöön toimita muutettu ohjelmisto laadunvalvontaan kunnes ohjelmiston laatu on hyväksytyllä tasolla luo uusi versio järjestelmästä muuten peru muutospyyntö muuten peru muutospyyntö Lomake määritellään versionhallinnan suunnittelussa Massatuotteiden tapauksessa muutospyynnöt perustuvat asiakkailta tulleisiin virheraportteihin Arvioidaan, mihin muihin moduuleihin muutos vaikuttaa CCB (Change control board) kokoonpano vaihtelee projektin koon mukaan Sommerville 2004!25

Muutospyyntölomake Projekti: Proteus/PCL-tools Numero: 23/02 Muutoksen pyytäjä: I. Sommerville Päivä: 1/12/02 Pyydetty muutos: Kun komponentti on valittu rakenteesta, näytetään tiedoston nimi, mihin se on talletettu Muutoksen analysoija: G. Dean Analyysi tehty: 10/12/02 Tarkasteltavat komponentit: Display-Icon.Select, Display-Icon.Display Liittyvät komponenetit: FileTable Muutoksen arviointi: Toteutus on kohtuullisen helppo, kun tiedoston nimitaulu on saatavilla. Vaatii näyttökentän suunnittelun ja toteutuksen. Liittyviin komponentteihin ei tule muutoksia. Muutoksen prioriteetti: alhainen Muutoksen toteutus: Arvioitu työpanos: 0.5 päivää Toimitettu hallintaryhmälle: 15/12/02 Hallintaryhmän päätös tehty: 1/2/03 Hallintaryhmän päätös: Hyväksy muutos. Muutos voidaan toteuttaa julkaisussa 2.1 Toimitettu laaturyhmälle: Laaturyhmän päätös: Toimitettu versionhallintaan: Sommerville 2004!26

Julkistusten hallinta Järjestelmän julkistus on asiakkaalle toimitettu versio. Julkistus on muutakin kuin koodia, esim. konfigurointitiedostot miten julkistus kootaan tiettyyn toimitukseen datatiedostot tarvitaan järjestelmän onnistuneeseen toimintaan asentamisohjelma ohjeet ja skriptit, kuinka järjestelmä asennetaan tietylle laitteistolle järjestelmän dokumentaatio Sommerville 2004!27

Julkistusten hallinta... Järjestelmän julkistuksen ajankohta on tärkeä liian tiheästi tehdyt julkistukset nähdään painolastina ei riittävästi uusia piirteitä ei haluta päivitystä, varsinkin jos se maksaa liian harvoin tehdyt julkistukset voi aiheuttaa asiakkaan menetyksen kilpailijan tuote uusine piirteineen tuntuu paremmalta Sommerville 2004!28

Julkistusstrategia - mikä aiheuttaa uuden julkistuksen? Tekninen laatu Alustan muutokset Lehmanin viides laki Kilpailu Markkinat Asiakkaan vaatima muutos Jos on raportoitu vakavista vioista (monilta asiakkailta), tarvitaan korjausjulkistus. Esim. käyttöjärjestelmän päivitys Uusien ominaisuuksien määrä uudessa julkistuksessa on keskimäärin vakio. Kilpailijan tulo markkinoille vaatii uuden julkistuksen. Markinointiosasto on luvannut uuden julkistuksen tiettyyn aikaan. Räätälöidyissä järjestelmissä asiakkaat ovat halunneet ja maksaneet muutoksista.!29

Miten ohjelmistot kehittyvät? Bash is the popular Unix shell. BIND is the leading DNS server on the Internet. Bison is the GNU parser generator. OpenSSH is the standard open-source suite of the widely used secure shell protocols. Quagga is a tool suite for building software routers that support the RIP, OSPF, and BGP protocols on top of IPv4. Samba is a tool suite that facilitates Windows-UNIX interoperability. Sendmail is the leading email transfer agent today. SQLite is a popular library implementation of a self-contained SQL database engine. Vsftpd stands for Very Secure FTP Daemon and is the FTP server in major Linux distributions. Neamtiu I., Xie G., Chen J., Journal on Software Maintenance and Evolution, 2011!30

Muutosten tilan seuranta Software Configuration Item voi olla dokumentti, testitapausten kooste tai yksittäinen ohjelma- komponentti SCIs Change Requests Change Change Request Form Request Form Change Reports ECOs Engineering Change Order Muutos on hyväksytty, odottaa toimenpiteitä Status Accounting Reporting!31

23. Tuotemetriikat Mittaamisen tavoitteena on saada Oikea tieto Oikeassa muodossa Oikeaan aikaan Oikeille ihmisille Mittaaminen (measurement) pyritään saamaan aikaan matemaattinen malli, joka kuvaisi johdonmukaisella asteikolla mitattavien kohteiden mitattavan ominaisuuden suuruuden Metriikka (metric, joskus myös measure) measurement function a software quality metric a function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality faults/hr!32

Miksi mitataan? Lisätään ymmärrystä mitattavasta kohteesta tuotteen valmiudesta, kompleksisuudesta, laadusta, virheettömyydestä mittaustulosten avulla tuotteita pystytään analysoimaan paremmin, ja niistä saadaan vertailukelpoista tietoa Päätöksenteon työkalu Motivoinnin työkalu!33

Toimintopohjaiset metriikat Toimintopistemetriikkaa (function point metric, FP), voidaan käyttää toimitettavan järjestelmän toiminnallisuuden, mutkikkuuden ja koon mittaamiseen. Albrecht 1979 Toimintopisteet saadaan järjestelmän ja ympäröivän maailman kommunikointia kuvaavista tiedoista. Toimintopisteiden laskentaan käytettävät tiedot ovat: ulkoisten syötteiden määrä (number of external inputs (EIs)) ulkoisten tulosteiden määrä (number of external outputs (EOs)) ulkoisten kyselyjen määrä (number of external inquiries (EQs)) sisäisten tietovastojen määrä (number of internal logical files (ILFs)) ulkoisten rajapintojen määrä (number of external interface files (EIFs))» http://www.softwaremetrics.com/fpafund.htm!34

Toimintopisteet x x x x x!35

Test sensor Sensors User Password Zone inquiry Sensor inquiry Panic button Activate/deactivate Password, sensors SafeHome User Interaction Function Zone setting Messages Sensor status Alarm alert User Activate/deactivate Monitoring & response subsystem EIs = password, panic button, activate/deactivate EOs= messages, sensor status EQs = zone inquiry, sensor inquiry ILFs = SCD EIFs = test sensor, zone setting, activate/deactivate, alarm alert System configuration data FP = count total * [0.65 + 0.01 * sum (F i )] 3 X 9 FP = 50 * [0.65 + (0.01 * 46)] = 56 1 FP e.g. 60 LOC, 1 person month effort e.g. 12 FP 2 2 1 4 X X X X 8 6 7 20 50!36

Metrics for Object-oriented design Weighted methods per class, WMC Number of methods and their complexity; WMC should be kept as low as is reasonable Depth of the inheritance tree, DIT The maximum length from the node to the root of the tree. As DIT grows, it leads to potential difficulties to predict the behavior of the class. Number of children, NOC When NOC increases, the abstraction presented by the parent class can be diluted (some of the children are not appropriate members of the parent class.) Coupling between object classes, CBO As CDO increases, reusability of the class may decrease. Response for a class, RFC A set of methods that can potentially be executed in response to a message received by an object of that class. As RFC increases, the effort required for testing also increases. Lack of cohesion in methods, LCOM Is the number of methods that access one or more of the same attributes. If no methods access the same attributes, then LCOM is 0. Chidamber and Kemerer 1994!37

QMOOD quality metrics and attributes First Level Second Level Third Level Fourth Level Design Quality Attributes Object- Oriented Design Properties Object- Oriented Design Metrics Object- Oriented Design Components Reusability Flexibility Understandability Coupling Cohesion Composition Encapsulation Design size Direct class coupling Cohesion among methods in class Measure of aggregation Data access metric Design size in classes!38

Bansiya & Davis 2002!39

Metrics are mainly based on metric suite of Chidamber & Kemerer (1994). Some metrics are new, because C&K metrics require a nearly complete implementation of classes. The new metrics are DAM DCC CAM MOA MFA Bansiya & Davis 2002!42

MFC = Microsoft Foundation Classes OWL = Object Windows Library Bansiya & Davis 2002!43

MFC = Microsoft Foundation Classes OWL = Object Windows Library Bansiya & Davis 2002!44

Luokkien väliset riippuvuussuhteet Epävakaus = Instability Alkion x epävakaus voidaan laskea kahden tekijän avulla Efferent Couplings (Ce) niiden alkioiden lukumäärä, joita x käyttää Afferent Couplings (Ca) niiden alkioiden lukumäärä, jotka käyttävät x:ää Instability (x) = Ce / (Ce + Ca) NDepend työkalulla voidaan tutkia koodin riippuvuuksia SELECT TOP 10 METHODS ORDER BY MethodCa DESC mitä ohjelman metodeja käytetään eniten jos Ca = 0, voi olla merkki kuolleesta koodista, jonka voi poistaa http://codebetter.com/blogs/patricksmacchia/archive/2008/02/15/codemetrics-on-coupling-dead-code-design-flaws-and-re-engineering.aspx Ca Code Element Ce!46