Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta (Samuel Lahtinen)
Tarjolla tänään Arkkitehtuuritietämys Arkkitehtuuripäätökset DCAR ja ATAM-arviointimenetelmä Jos aikaa, niin uudenkarheaa juttua arviointirintamalta
Mitä on ohjelmistoarkkitehtuurin arviointi? Ohjelmistoarkkitehtuurin arviointi tarkoittaa toimintaa, jonka avulla voidaan tehdä johtopäätöksiä siitä, miten hyvin tietty ohjelmistoarkkitehtuuri tukee ko. järjestelmän vaatimusten toteutumista 26.2.2016 Ohjelmistoarkkitehtuurit 2016 3
Miksi ohjelmistoarkkitehtuuria on arvioitava? Arkkitehtuuri on ensimmäinen täsmällinen kuvaus järjestelmästä Arviointi vahvistaa hyvät ratkaisut ja kiinnittää huomiota mahdollisiin ongelmiin aikaisin Arviointi auttaa ymmärtämään paremmin järjestelmää 26.2.2016 Ohjelmistoarkkitehtuurit 2016 4
Muita mahdollisia hyötyjä Kehitystrendien sekä potentiaalisten kehitys- ja riskialueiden tunnistaminen Ohjelmiston uudistaminen ja tärkeimpien uudistuskohteiden tunnistaminen ja päätösten läpikäynti Mahdollisuudet laajentaa toimintaa uudelle toimialalle, arviointia tarvittavista muutoksista Arvioinnilla voidaan varmistua muiden tekemien ohjelmistojen (esim. alihankinta) laadusta Arkkitehtuurin suunnittelua ohjaavien laatuvaatimusten kirjaaminen ja tarkentaminen Arkkitehtuuriratkaisuiden kirjaaminen ja liittäminen laatuvaatimuksiin Arkkitehtuuridokumentaation parantaminen Kommunikaation lisääminen 26.2.2016 Ohjelmistoarkkitehtuurit 2016 5
Milloin ohjelmistoarkkitehtuuria kannattaa arvioida? Ensimmäisten (vaihtoehtoisten) luonnosten pohjalta (alustava arkkitehtuuridokumentti) Arkkitehtuurisuunnittelun jälkeen, ennen toteutuksen aloittamista (järjestelmä / alijärjestelmäarkkitehtuuridokumentti) Olemassa olevalle järjestelmälle (esim. vanhan järjestelmän uudistaminen) Refaktorointitarve, kun havaitaan ongelmia, mitä pitää paikata 26.2.2016 Ohjelmistoarkkitehtuurit 2016 6
Arkkitehtuuritietämys Tang et al 2009
Arkkitehtuuritietämyksen kategoriat Farenhorst, de Boer 2009
Ongelma Tietämyksellä on jalat ja se voi pudota tikkailta tai saada paremman tarjouksen
Kuva:http://www.ibm.com/developerworks/opensource/library/wa-eclipsemvc/index.html
42010 Standard
42010 std (cont)
Dokumentoidaan molemmat Perustelut
Arkkitehtuuripäätökset Software architecture is the composition of a set of architectural design decisions Jansen & Bosch, 2005 Architecting is making decisions. The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark Philippe Kruchten
Päätösten dokumentointi Dokumentoidaan arkkitehtuuripäätökset sitä mukaan kun niitä tehdään + Perustelut päätöksille olemassa pitkänkin ajan jälkeen +-Lisää dokumentoinnin määrää - Voi olla liian raskasta Erilaisia dokumentointimalleja
Päätösten dokumentointiesimerkki 1 Tyree & Akerman 2005
Päätösten dokumentointiesimerkki 2 Van Heesch, Avgeriou, Hilliard
Päätösten dokumentointi (TUT/RUG) Name Problem Solution / description of decision Considered alternative solutions Arguments in favour of decision Arguments against the decision Outcome Rationale for outcome
DCAR Kehitetty TTY:n ohjelmistotekniikan laitoksella yhteistyössä Groningen Yliopiston kanssa TTY:llä kokemusta ATAM arvioinneista Groningenilla arkkitehtuuritietämyksen hallinnasta ja päätösten dokumentoinnissa Koearviointeja suomalaisissa ohjelmistoyrityksissä ja TTY:llä Julkaistu IEEE Software journalissa Laajempi kirjan luku työjonossa www.dcar-evaluation.com
DCAR-menetelmän tavoitteet Kevyt, ketterä, ja iteratiivinen Inkrementaalinen ja iteratiivinen Ongelma-avaruuden laajempi huomiointi Ei vain laatuominaisuudet, vaan muutkin asiat Arvioinnin kattavuus jotenkin arvioitavissa Säilyttää ATAM menetelmän vahvuudet (kommunikaation lisääminen, dokumentaation parantaminen, jne)
Osallistujat Yrityksen / projektin edustajat Järjestelmän arkkitehti Projektipäällikkö, PO, Tuotepäällikkö, tms Sovelluskehittäjät Sovellusalueen asiantuntijat Arviointiryhmä Arvioinnin vetäjä 2 x Kirjuri Decision scribe Forces scribe Kyseenalaistaja(t)
Mystinen force -käsite Arkkitehtuuripäätöksiin vaikuttaa erilaiset tekijät Suunnittelua ohjaavat laatuvaatimukset, kuten suorituskyky, muunneltavuus (kuten ATAMissa) Lisäksi kuitenkin monet reunaehdot vaikuttavat päätöksen tekoon: kustannukset, aikataulupaine, alihankintasopimukset, jne Jotkut vaikuttavista tekijöistä on hiljaista tietoa, esim. arkkitehdin mielipide, sovellusalueen tuntemus Kaikki yllämainitut ovat arkkitehtuuritietämystä ja tulisi siten dokumentoida
Force esimerkki <<Force>> I would like to use NoSQL!
Forcet (jatkuu)
Metamalli forceista
Force tyyppejä Explicit forces Requirements Existing constraints Constraints for future decisions Technical risks General software engineering principles (e.g. high cohesion, low coupling) other decisions business goals (low price, quick time2market, innovation, ) business model business constraints (available licenses, ) company politics Tacit forces organization culture organization structure other decisions experience expertise intuition and bias the software development process impediments laws/regulations politics time preasure historical decisions
Iteraatio DCAR vaiheet 1. Arvioinnin valmistelu 2. DCAR menetelmän esittely 3. Sovellusalueen ja liiketoimintatavotteiden esittely 4. Arkkitehtuurin esittely 5. Päätösten katselmointi ja priorisointi 6. Päätösten dokumentointi 7. Päätösten analyysi 8. Retrospektiivi ja tulosten raportointi
Vaihe 1: Valmistelu Arvioijat sopivat yrityksen kanssa arviointipäivän ja paikan Arvoinnin rajaus (mikä järjestelmä, mitkä järjestelmän osat arvioidaan) Arvioinnin tavoite? Mitä tuloksilla tehdään, mistä asioista ollaan kiinnostuneita? Ketkä pitävät esitykset? Arkkitehtuuridokumentaation nykytila? Tarvitaanko lisää? Arvioijat lukevat olemassa olevan arkkitehtuuridokumentaation Esitysten tarkastus etukäteen
Vaihe 2: DCAR esitys 15 minuutin DCAR esitys Tärkeimmät vaiheet kerrataan vielä juuri ennen vaiheen suoritusta DCAR esittelymateriaali jaetaan osallistujille etukäteen, jotta voivat esittää kysymyksiä epäselviksi jääneistä asioista
Vaihe 3: Liiketoimintatavoitteiden esittely Product owner tai tuotepäällikkö pitää 15 minuutin esityksen liiketoimintatavotteista ja sovellusalueesta Arvioijat pyrkivät tunnistamaan forceja, jotka voivat olla vaikuttaneet päätöksiin (joko tietoisesti tai tiedostamatta)
Tehtävä 1: forcejen tunnistelu Kuuntele esitys ja tunnista forcet
Vaihe 4: Arkkitehtuuriesitys Arkkitehti pitää 45 minuutin esityksen arkkitehtuurista Arvioijat kysyvät tarkentavia kysymyksiä Arvioijat koittavat tunnistaa tehtyjä arkkitehtuuripäätöksiä 2016 Forceja kerätään edelleen Arvioijat tekevät arkkitehtuuripäätösten suhteita kuvaavan graafin (decision relationship view)
Tehtävä 2: arkkitehtuuripäätökset Tunnista järjestelmästä arkkitehtuuripäätöksiä ja listaa niitä
Vaihe 5: Päätösten katselmointi ja priorisointi Arvioijat näyttävät alustavan listan tunnistettuja arkkitehtuuripäätöksiä muille osallistujille Lista täydennetään osallistujien kanssa Päätösten nimiä tarkennetaan jos aihetta ilmenee Kaksivaiheinen päätösten priorisointi: Aluksi jokainen stakeholder valitsee 3-5 päätöstä, jotka hän haluavat arvioitavan Näin muodostuu short list. Päätökset, jotka eivät saaneet ääniä jätetään tarkastelun ulkopuolelle Vaihe 2: Jokaisella stakeholderilla on käytössään 100 pistettä, jotka hän voi jakaa short listin päätöksille, miten haluaa. Päätös, jolla on eniten pisteitä arvioidaan ensin
Vaihe 6: Päätösten dokumentointi Jokainen stakeholder valitsee 1-3 päätöstä, jotka ovat hänelle tuttuja ja dokumentoi ne Arvioijat auttavat stakeholdereita dokumentoimaan päätökset Yleensä arvioijat antavat stakeholdereille esimerkkipäätöksen, josta voi katsoa mallia dokumentoinnissa Osa arvioijatiimistä viimeistelee päätösten suhteita kuvaavan graafin ja yhdistävät force-listansa
Vaihe 6: Päätöksen dokumentointi Name Problem Solution / description of decision Considered alternative solutions Arguments in favour of decision Arguments against the decision Outcome Redundancy of the controllers The application should run even if one of the redundant servers fail. Solution goes here. <Solution removed for confidentiality reasons> Both redundant server members could be active. Easier to implement. Slower switchover No possibility to offer more availability than current 99.99 %. Rationale for outcome
Päätösten dokumentointi (TUT/RUG) Name Problem Solution / description of decision Considered alternative solutions Arguments in favour of decision Arguments against the decision Outcome Rationale for outcome
Vaihe 7: Päätösten analyysi Stakeholder, joka dokumentoi päätöksen esittelee sen muulle porukalle Toiset stakeholderit voivat kysyä kysymyksiä ja ehdottaa täydennyksiä päätöksen dokumentointiin Kirjuri kirjoittaa täydennykset päätökseen tarpeen mukaan Arvioijat kyselevät päätöksestä ja yrittävät löytää uusia argumentteja päätöksen puolesta ja vastaan (nämä myös kirjataan dokumentaation tarpeen mukaan) Arvioijat käyttävät forces listaa keksiäkseen uusia kysymyksiä. 10-15 minuutin jälkeen analyysi ja keskustelu päättyy (poliisi pitää huolen kellotuksesta). Tällöin stakeholderit äänestävät onko päätös edelleen validi vai onko ilmennyt uutta tietoa, joka aiheuttaa päätöksen miettimisen uudelleen. Stakeholderit äänestävät yhtäaikaisesti peukalollaan (Peukku ylös, alas tai siltä väliltä)
Vaihe 8: Retrospektiivi ja raportointi Lopuksi pidetään lyhyt keskustelutilaisuus, miten arviointi sujui. Mitä voisi parantaa arvioijien toiminnassa, yms Tulokset raportoidaan mahdollisimman pian kirjallisesti
Lopputulos Analysoitu päätös Name Problem Solution / description of decision Redundancy of the controllers The application should run even if one of the redundant servers fail. Solution goes here. Removed for confidentiality reasons.. Considered alternative solutions Both redundant server members could be active. Arguments in favour of decision Arguments against the decision Easier to implement. Slower switchover No possibility to offer more availability than current 99.99 %. Outcome Yellow Yellow Red Green Rationale for outcome Rationale why yellow goes here..
Decision relationship view <<duplicate>> Address translator <<duplicate>> <<is alternative of>> <<rejected>> In-house scheduler <<rejected>> Redundancy monitor Kernel
Force taulukko Päätös 1 Päätös 2 Päätös 3 Päätös 4
Arviointiraportti Glossary 1. Introduction 1.1. Purpose and Scope 1.2. Review participants 1.2.1. Stakeholders 1.2.2. Review team 1.3. DCAR process description 1.4. Realization of the process 2. System overview 3. Architectural decisions 3.1. Decision relationship view 3.2. Prioritization of decisions 3.3. Detailed decision documentation 3.4. Traceability matrix for decisions forces and decisions 4. Potential risks, issues and indicators for technical debt 4.1. Risk X in detail 4.2. Risk Y in detail 5. Conclusions References
DCAR hyötyjä Näkyvyys, tekee väärät päätökset näkyväksi Kevyt (kestää 4 tuntia + lounas) Vielä nopeampi jos päätökset ovat valmiiksi dokumentointu Sallii inkrementaalisuuden (ei näyttöä teollisuudesta!) Ei hukkaa (waste) (vs. Skenaariot ATAMissa) Lopputulos suoraan hyödynnettävissä osana arkkitehtuuridokumentaatiota Lisäksi ATAMin höydyt
Heikkouksia Arkkitehtuuripäätös konseptina uusi teollisuudessa => melko vähän käytössä Tarkastelee järjestelmän nykytilaa. Mikäli arvioijat eivät ole tarkkoina saattaa jotain odotettuja muutoksia jäädä huomaamatta (vrt. ATAM kasvuskenaariot) Vaatii kokeneita arvioijia (?)
Kysyttävää?
DCAR ohjelma 09:45-10:00 Opening words, coffee 10:00-10:15 Presentation of DCAR method 10:15-10:30 Business presentation 10:30-11:15 Architecture presentation 11:15-11:30 Break 11:30-12:00 Decision overview & prioritization 12:00-12:45 Lunch 12:45-13:15 Decision documentation 13:15-14:00 Decision evaluation 14:00-14:15 Break 14:15-15:00 Decision evaluation 15:00-15:15 Feedback & retrospective