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

Transkriptio

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

2 Tarjolla tänään Arkkitehtuuritietämys Arkkitehtuuripäätökset DCAR ja ATAM-arviointimenetelmä Jos aikaa, niin uudenkarheaa juttua arviointirintamalta

3 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 Ohjelmistoarkkitehtuurit

4 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ää Ohjelmistoarkkitehtuurit

5 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 Ohjelmistoarkkitehtuurit

6 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 Ohjelmistoarkkitehtuurit

7 Arkkitehtuuritietämys Tang et al 2009

8 Arkkitehtuuritietämyksen kategoriat Farenhorst, de Boer 2009

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

10 Kuva:

11 42010 Standard

12 42010 std (cont)

13 Dokumentoidaan molemmat Perustelut

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

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 työjonossa

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

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 Tehtävä 1: forcejen tunnistelu Kuuntele esitys ja tunnista forcet

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

33 Tehtävä 2: arkkitehtuuripäätökset Tunnista järjestelmästä arkkitehtuuripäätöksiä ja listaa niitä

34 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

35 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

36 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

37 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

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

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

40 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..

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

42 Force taulukko Päätös 1 Päätös 2 Päätös 3 Päätös 4

43 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

44 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

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

46 Kysyttävää?

47 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