Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta 22.02. 2012 Tarjolla tänään Arkkitehtuuritietämys Arkkitehtuuripäätökset DCAR -arviointimenetelmä Arkkitehtuuritietämys Tang et al 2009 1
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 2
42010 Standard 42010 std (cont) Dokumentoidaan molemmat Perustelut 3
Arkkitehtuuripäätökset Software architecture is the composition of a set of architectural design s Jansen & Bosch, 2005 Architecting is making s. The life of a software architect is a long (and sometimes painful) succession of suboptimal s 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 4
Päätösten dokumentointiesimerkki 2 Van Heesch, Avgeriou, Hilliard Päätösten dokumentointi (TUT/RUG) Name Problem Solution / description of Considered alternative solutions Argument in favour of Argument against the 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ä Tutkimushanke jatkuu edelleen (kurssilla kerätään dataa) 5
DCAR-menetelmän tavoitteet Kevyt, ketterä, ja muita hypesanoja Inkrementaalinen ja iteratiivinen Ongelma-avaruuden laajempi huomiointi Arvioinnin kattavuus jotenkin arvioitavissa Säilyttää ATAM menetelmän vahvuudet (kommunikaation lisääminen, dokumentaation parantaminen, jne) 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! 6
DCAR vaiheet 1. Arvioinnin valmistelu 2. DCAR menetelmän esittely 3. Sovellusalueen ja liiketoimintatavotteiden esittely 4. Arkkitehtuurin esittely Iteraatio 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? 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 7
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) Vaihe 4: Arkkitehtuuriesitys Arkkitehti pitää 45 minuutin esityksen arkkitehtuurista Arvioijat voivat kysyä tarkentavia kysymyksiä Arvioijat koittavat tunnistaa tehtyjä arkkitehtuuripäätöksiä Forceja kerätään edelleen Arvioijat tekevät arkkitehtuuripäätösten suhteita kuvaavan graafin ( relationship view) 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 8
Vaihe 6: Päätösten dokumentointi Jokainen stakeholder valitsee 1-3 päätöstä, jotka ovat hänelle tuttuja ja dokumentoi Arvioijat auttavat stakeholdereita dokumentoimaan päätökset Yleensä arvioijat antavat stakeholdereille esimerkki päätöksen, josta voi katsoa mallia 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 Considered alternative solutions Argument in favour of Argument against the 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 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 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 Stakeholderit äänestävät yhtäaikaisesti peukalollaan (Peukku ylös, alas tai siltä väliltä) 9
Vaihe 8: Retrospektiivi ja raportointi Lopuksi pidetään lyhyt keskustelutilaisuus, miten arviointi sujui. Mitä voisi arvioijien toiminnassa, yms Tulokset raportoidaan mahdollisimman pian kirjallisesti Lopputulos Analysoitu päätös Name Problem Solution / description of 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. Argument in favour of Easier to implement. Argument against the 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 10
Force matrix 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 s 3.1. Decision relationship view 3.2. Prioritization of s 3.3. Detailed documentation 3.4. Traceability matrix for s forces and s 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 11
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 12