Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta

Transkriptio

1 Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta

2 Tarjolla tänään Lyhyesti arkkitehtuuritietämyksestä Arkkitehtuuripäätökset DCAR -arviointimenetelmä

3 Arkkitehtuuritietämys - määritelmä Dingsᴓyr: Architecture Knowledge = Architecture Design + Architecture Design Decisions Farenhorst & de Boer: Ei ole olemassa yhtä hyvää määritelmää

4 Arkkitehtuuritietämystyypit Context knowledge Tietoa ongelmakentästä, esim. Arkkitehtuurillisesti merkittävät vaatimukset, projektin konteksti, jne General knowledge Yleinen suunnittelutietämys, esim. Patternit, arkkitehtuurityylit, taktiikat (tactics), jne Reasoning knowledge Perustelevaa tietoa, esim. Suunnittelupäätökset ja niiden perustelut, trade-offs, jne Design knowledge Tietoa järjestelmän designista, kaaviot, mallit, komponenttijako, jne

5 Arkkitehtuuritietämys Tang et al

6 Arkkitehtuuritietämyksen kategoriat Farenhorst, de Boer 2009

7 Ongelma Tietämyksellä on jalat ja se voi pudota tikkailta tai saada paremman tarjouksen

8 Kuva:

9 Kuva:

10 42010 Standard

11 42010 std (cont)

12 Dokumentoidaan molemmat Perustelut

13 Arkkitehtuuripäätökset Esimerkkipäätöksiä: Käytämmekö tässä projektissa node.js:ää vai jotain muuta teknologiaa? Suunnittelemmeko clientin MVC-mallin mukaisesti? Päätös voi aiheuttaa muita päätöksiä: Teemme ios-clientin => clientissa MVC.

14 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

15 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 Ei pelkästään tehdyt päätökset, mutta myös vaihtoehtoiset ratkaisumallit

16 Päätösten dokumentointiesimerkki 1 Tyree & Akerman 2005

17 Päätösten dokumentointiesimerkki 2 Van Heesch, Avgeriou, Hilliard

18 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

19 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 julkaistaan lähi aikoina Tutkimushanke jatkuu edelleen (kurssilla kerätään dataa)

20 DCAR-menetelmän tavoitteet Kevyt ja ketterä 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)

21 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)

22 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

23 Force esimerkki <<Force>> I would like to use NoSQL!

24 Forcet (jatkuu)

25 Metamalli forceista

26 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

27 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

28 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

29 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

30 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)

31 Vaihe 4: Arkkitehtuuriesitys Arkkitehti pitää 45 minuutin esityksen arkkitehtuurista Arvioijat kysyvät tarkentavia kysymyksiä Arvioijat koittavat tunnistaa tehtyjä arkkitehtuuripäätöksiä 2014 Forceja kerätään edelleen Arvioijat tekevät arkkitehtuuripäätösten suhteita kuvaavan graafin (decision relationship view)

32 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

33 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

34 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 %. Rationale for outcome

35 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ä 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ä)

36 Vaihe 8: Retrospektiivi ja raportointi Lopuksi pidetään lyhyt keskustelutilaisuus, miten arviointi sujui. Mitä voisi parantaa arvioijien toiminnassa, yms Tulokset raportoidaan mahdollisimman pian kirjallisesti

37 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 %. Outcome Yellow Yellow Red Green Rationale for outcome Rationale why yellow goes here..

38 Decision relationship view <<duplicate>> Address translator <<duplicate>> <<is alternative of>> <<rejected>> In-house scheduler <<rejected>> Redundancy monitor Kernel

39 Force taulukko Force Päätös 1 Päätös 2 Päätös 3 Päätös 4 Long product lifecycles Long update cycle in industry, e.g. 10 years Connections to other systems (ERP, MES, CMMS) Wireless devices & operator software Windows OS in all systems ++

40 Arviointiraportti Glossary 1. Introduction 1.1. Purpose and Scope 1.2. Review participants Stakeholders 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

41 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

42 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 (?)

43 Kysyttävää?

44 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