Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ...ohar/luennot/luennot2009/Ohar9...

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

9. Ohjelmistoarkkitehtuurien arviointi9. Ohjelmistoarkkitehtuurien arviointi

JohdantoATAM-menetelmäEsimerkkiKäytännön kokemuksia ja ongelmiaYhteenveto

Miksi ohjelmistoarkkitehtuuria on arvioitava?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 Syksy 2009 TTY Ohjelmistotekniikka

Muita mahdollisia hyötyjäMuita mahdollisia hyötyjä

• Kehitystrendien sekä potentiaalisten kehitys- ja riskialueiden tunnistaminen

• 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

Milloin ohjelmistoarkkitehtuuri olisi arvioitava?Milloin ohjelmistoarkkitehtuuri olisi arvioitava?

• Ensimmäisten (vaihtoehtoisten) luonnosten pohjalta (alustava arkkitehtuuridokumentti)

• Arkkitehtuurisuunnittelun jälkeen, ennen toteutuksenaloittamista (järjestelmä/alijärjestelmäarkkitehtuuri-dokumentti)

• Olemassaolevalle järjestelmälle (esim. vanhan järjestelmän uudistaminen)

Arkkitehtuurin rakentaminen kehitysprosessissaArkkitehtuurin rakentaminen kehitysprosessissaArkkitehtuurin kannalta merkittävät vaatimukset

Alustavaarkkitehtuuri

Vaatimus-analyysi

Arkkitehtuurinarviointi

Alustavaarkkitehtuuri-suunnittelu

Laatu-vaatimuksenhuomiointi

Keskeisettoiminnallisetvaatimukset

Laatu-vaatimukset

Arkkitehtuuri

Kaikkikäsitelty

Toissijaisettoiminnallisetvaatimukset

Rajoitteet

Yksityiskohtainensuunnittelu

Yleisten ratkaisu-mallien soveltaminen

Arkkitehtuuri-muunnos

Ympäristö-vaatimukset

Arkkitehtuuri ja laatuvaatimuksetArkkitehtuuri ja laatuvaatimukset

• Tässä laadulla ei viitata virheettömyyteen vaan siihen millä laadulla järjestelmä tekee loogiset toimintonsa

• Arkkitehtuuri määrää miten (useimmat) laatuvaatimuksettoteutuvat. Hiukan kärjistäen: Ohjelmistoarkkitehtuuri on tapa toteuttaa ohjelmiston laatuvaatimukset

• Arkkitehtuurin kuvauksen täytyy sisältää kaikki se informaatio, joka tarvitaan päättelemään laatuvaatimustentoteutuminen tai toteutumattomuus

• Arkkitehtuuria arvioidaan (yleensä) vasten laatuvaatimuksia

Ohjelmistojen laatuominaisuudetOhjelmistojen laatuominaisuudet

Ajoaikaiset laatuominaisuudet

• Suorituskyky• Tilankäyttö• Luotettavuus• Saatavuus• Tietoturvallisuus• Käytettävyys• …

Kehitys- ja evoluutioaikaiset laatuominaisuudet:

• Muunneltavuus• Siirrettävyys• Ylläpidettävyys• Uudelleenkäytettävyys• …

Laatustandardit: esim. ISO 9126

ISO 9126 laatukehikkoISO 9126 laatukehikko

Tarkennetut laatuominaisuudetTarkennetut laatuominaisuudet

EfficiencyTime performanceResource utilizationResponse timeMemory usageScalabilityThroughput

MaintainabilityAnalyzabilityChangeabilityStabilityTestabilityVariabilitySubsetabilityConceptual integrityTraceability

ReliabilityMaturityFault toleranceRecoverabilityAvailabilityPredictability

UsabilityUnderstandabilityLearnabilityOperabilityAttractiveness

PortabilityAdaptabilityInstallabilityCo-existenceReplaceability

FunctionalitySuitabilityAccuracyInteroperabilitySecurityData securityAccess security

Safety

Ryhmittelyllä ei käytännössä paljon merkitystä arvioinnissa

Arkkitehtuuri ja liiketoimintatavoitteetArkkitehtuuri ja liiketoimintatavoitteet

Arvioinnin tulokset Arvioinnin tulokset

Ohjelmistoarkkitehtuurin arviointi vastaa tyypillisesti seuraaviinkysymyksiin:

1) Täyttääkö suunniteltu arkkitehtuuri olennaiset laatuvaatimukset? Jos täyttää, miksi? Jos ei täytä, miksi?

2) Mikä vaihtoehtoisista arkkitehtuuriratkaisuista sopii parhaiten järjestelmälle? Miksi?

3) Kuinka hyvin tietty laatuvaatimus voidaan saavuttaa suunnitellulla arkkitehtuurilla?

VarauksiaVarauksia

• Arviointi pohjautuu arkkitehtuurin kuvaukseen, saatavilla olevaan informaatioon ja osallistujien aktiivisuuteen

• Arvioinnin tulosten tarkkuus riippuu lähtötietojen tarkkuudesta

• Arvioinnissa täytyy olettaa järkevä toteutus, arkkitehtuurin täytyy mahdollistaa järkevä toteutus

Ohjelmistoarkkitehtuurien arvioinnin ongelmaOhjelmistoarkkitehtuurien arvioinnin ongelma

Laatu-vaatimukset

Ohjelmisto-arkkitehtuuri

Laatuvaatimukset tulevat sidosryhmiltäLaatuvaatimukset tulevat sidosryhmiltä

Loppukäyttäjä

Hyvä suorituskyky, luotettava,hyvä käytettävyys

Ylläpitäjä

Helposti ylläpidettävä,siirrettävä

Laatuominaisuuksien arviointiLaatuominaisuuksien arviointi

• Laatuominaisuuksille ei ole selviä täyttymiskriteerejä• Esim. ylläpidettävyys: järjestelmän on oltava helppo

muuttaa kun sen käyttöympäristö muuttuu• Miten arvioida jotain ominaisuutta, jolla on suuri (ääretön)

määrä erilaisia tilanteita, joissa ominaisuuden olemassaolo on potentiaalisesti uhattuna

• Vrt. oikeellisuus – testaus• Yleinen menetelmä: määrää tavoitteet järjestelmälle,

johda niistä halutut laatuominaisuudet, tarkenna ne, anna kullekin tarkennetulle laatuominaisuudelle esimerkki-tilanne, ja tutki täyttyykö ko. laatuominaisuus tässä esimerkkitilanteessa

Laatuvaatimusten täsmentäminen Laatuvaatimusten täsmentäminen skenaarioillaskenaarioilla

• Skenaario = tilanne tai tapahtumasarja, joka tuo esille jonkin laatuvaatimuksen täyttymisen (jonkin järjestelmän osan kannalta)

• Skenaario konkretisoi laatuvaatimuksen esimerkillä• Skenaarion on oltava riittävän täsmällinen, jotta

arkkitehtuuria voidaan arvioida sitä vasten – usein tarkkoja lukuarvoja

• Vrt. perinteinen käyttötapaus – toiminnallinen vaatimus• Skenaario = arkkitehtuurin testitapaus

Tiedon louhinta arkkitehtuurista Tiedon louhinta arkkitehtuurista

• Asiantuntijoiden näkemyksetesim. pääarkkitehti, muita vastaavia järjestelmiäsuunnitelleet arkkitehdit ym.

• Takaisinmallinnuskoodia voidaan abstrahoida takaisinmallinnustyökaluilla, ei tuota varsinaista arkkitehtuurikuvausta vaan analysoi erilaisia riippuvuuksia

• Simulointijos on olemassa ajettava malli, voidaan tutkia arkkitehtuurista johtuvaa suorituskykyä, luotettavuutta; edellyttää järjestelmän mallintamista ja hyvää työkalua

• Metriikatvoidaan käyttää karkeana työkaluna epäilyttävien kohtienlöytämiseen (toimii lähinnä ylläpidettävyydelle),edellyttää hyviä työkalujaesim. suuret luokat, paljon riippuvuuksia komponenttien välillä

Analysointityökalujen hyödyntäminenAnalysointityökalujen hyödyntäminen

• Olemassaolevan järjestelmän arkkitehtuuriarvioinnissa voidaan käyttää erilaisia työkaluja (esim. metriikkatyökalut, sääntöjen tarkistustyökalut, visualisointityökalut, riippuvuusanalysaattorit, koodin kopioinnin tarkistajat, takaisinmallinnustyökalut) (esim. Rigi, Columbus)

• Erityisen hyödyllistä ylläpidettävyyden ja muunneltavuuden analysoinnissa

• Monet työkalut toimivat koodin perusteella -> ei välttämättä arkkitehtuuritason informaatiota

• Voidaan hyödyntää skenaariopohjaisessa arvioinnissa esim. hakemalla ja priorisoimalla skenaarioita, jotka kohdistuvat ”epäilyttäviin” osiin järjestelmässä

Esimerkki (Columbus): koodin kopiointiEsimerkki (Columbus): koodin kopiointi

Ohjelmistoarkkitehtuurien arvioinnin ongelman Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: skenaariopohjainen arviointiratkaisu: skenaariopohjainen arviointi

Laatu-vaatimukset

Skenaariot

Vaatimustentarkennus

Arkkitehtuuri-ratkaisut

Ratkaisujenidentifiointi

Analyysi

Ohjelmistoarkkitehtuurien arvioinnin ongelman Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: tarkistuslistapohjainen arviointiratkaisu: tarkistuslistapohjainen arviointi

Laatu-vaatimukset

Yleinentarkistuslista

Analyysi

Sovitettutarkistuslista

Järjestelmätyyppi

yleiset/järjestelmätyyppikohtaiset tarkistuslistat:esim.: onko käyttöliittymäosat erotettu selvästi sovelluslogiikasta? onko kerrosten välillä selvät rajapinnat? onko tietokanta abstrahoitu yleisen rajapinnan taakse?

Skenaariopohjaiset arviointimenetelmätSkenaariopohjaiset arviointimenetelmätSAAM (Software Architecture Analysis Method)• keskittyy erityisesti muunneltavuuteen, siirrettävyyteen, ylläpidettävyyteen• kehitetty SEI:ssä• perustuu evoluutioaikaisiin skenaarioihin

ATAM (Architecture Tradeoff Analysis Method)• soveltuu kaikille laatuominaisuuksille• kehitetty SEI:ssä• johdettu SAAM:ista

MPM (Maintenance Prediction Method)• keskittyy ylläpidettävyyteen• pyrkii löytämään suht. tarkat kustannusarviot ylläpidolle• Jan Bosch:in kehittämä• perustuu ylläpitoskenaarioihin

ATAM tietovuoATAM tietovuo

Len Bass

ATAMin peruskäsitteetATAMin peruskäsitteet

Skenaario: arkkitehtuurin ”testitapaus”Laatupuu: kohdejärjestelmän laatuvaatimusten tarkennus asteittain skenaarioiksi (utility tree)Herkkyyskohta: muutokset tämän arkkitehtuuripäätöksen suhteen voivat aiheuttaa merkittäviä muutoksia johonkin laatuominaisuuteen (sensitivity point)Tasapainokohta: arkkitehtuuripäätös joka vaikuttaa useampaan laatuominaisuuteen vastakkaisiin suuntiin (tradeoff)Riski: arkkitehtuuripäätös joka saattaa aiheuttaa ongelmia tulevaisuudessa laatuattribuutin näkökulmastaEi-riski: arkkitehtuuripäätös joka voi edesauttaa laatuominaisuuden toteutumisessa

Skenaariot ja skenaariolajitSkenaariot ja skenaariolajit

Skenaario konkretisoi laatuvaatimuksen esimerkillä. Tapahtuma tai tapahtumasarja, joka liittyy johonkin laatuvaatimukseen.Skenaario on täsmällinen (vrt. testitapaus, use case)Skenaarion rakenne: Ärsyke - Ympäristö – VasteKäyttötapausskenaario: käyttäjän interaktio järjestelmän kanssa

Etäkäyttäjä hakee tietokantaraportin web-käyttöliittymästä suurimman kuormahuipun aikana ja saa sen 5s kuluessa.

Kasvuskenaario: ennakoituja muutoksiaJärjestelmään lisätään uusi datapalvelin latenssin vähentämiseksi 2,5s, työ tehdään 1 henkilötyöviikossa.

Tutkiva skenaario: odottamattomia muutoksia, kuormituksia jne.Puolet palvelimista kaatuu normaalissa käyttötilanteessa, tämä ei vaikuta järjestelmän saavutettavuuteen.

Skenaario esimerkkiSkenaario esimerkki

Skenaarion priorisointiSkenaarion priorisointi

• Tavallisesti kaksiosainen prioriteetti: • kuinka tärkeä (tuotepäällikkö, projektipäällikkö)• kuinka vaikea toteuttaa (arkkitehti)

• Kolme arvoa: H (high), M (medium), L (low)

• Voidaan tehdä myös äänestämällä

HarjoitusHarjoitus

Anna muunneltavuuteen liittyvä skenaario robotinvalmistajan tuotannonohjausjärjestelmälle

Anna turvallisuuteen liittyvä skenaario hissinohjausjärjestelmälle

Esimerkki: laatupuuEsimerkki: laatupuu

Suorituskyky

Muunneltavuus

Saatavuus

Tietoturvallisuus

laatuominaisuudet skenaariottarkennukset

TransaktioidenKäsittely

Vasteaika

GUI muutokset

Tietokanta-muutokset

Laitteistoviat

Palvelimenkaatuminen

Korttien käyttö

Käsittelee 1000 palvelupyyntöä/sek. (H,M)Käyttäjävarmistus < 1 sek. (H,M)

GUI Web-pohjaiseksi1 kk:ssa (M,H)

Tietokanta vaihdetaanOracleksi 6 kk:ssa (L,H)

Palvelimen kovalevyn hajoamisenjälkeen uusintakäynnistys5 min:ssa (L,H)

Uudelleenkäynnistysautentikaatiopalvelimen kaatuessa 5 min:ssa (M,M)

Luottokortin tiedot turvassa99.999% (H,L)

HerkkyyskohtaHerkkyyskohta

Herkkyyskohta = arkkitehtuuriratkaisu, joka on kriittinen jonkin laatuominaisuuden saavuttamisen kannalta.

Esimerkki:

MVC-mallin käyttö GUI arkkitehtuurissa on olennaista järjestelmän siirrettävyyden kannalta.

TasapainokohtaTasapainokohta

Tasapainokohta = herkkyyskohta, joka koskee useaalaatuominaisuutta (yleensä vastakkaisiin suuntiin)

Esimerkki:

XML:n käyttö syöttöformaattina parantaa järjestelmän integroitavuutta mutta heikentää sen suorituskykyä.

RiskiRiski

Riski = potentiaalisesti ongelmallinen arkkitehtuuriratkaisu, joka voi heikentää jotain laatuominaisuutta

Riski = ratkaisu/fakta + laatuseuraamus + perustelu

Esimerkki:

Kriteerit ja säännöt keskimmäisen kerroksen komponenttientekemiselle ovat epäselvät (ratkaisu/fakta). Tästä voi seuratatoiminnallisuuden replikointia eri kerroksissa (perustelu), mikä heikentää ylläpidettävyyttä (laatuseuraamus).

EiEi--riskiriski

Ei-riski = arkkitehtuuriratkaisu, jolla on tiedossa (lähinnä) vain hyviä laatuseuraamuksia.

Ei-riski = oletus + ratkaisu + laatuseuraamus + perustelu

Esimerkki:Olettaen, että komponentit eivät joudu tutkimaan toistensa tilaa (oletus), Tarkkailija-suunnittelumallin käyttö komponenttien välisessä kommunikoinnissa (ratkaisu) parantaa muunneltavuutta (laatuseuraamus), koska komponenttien ei tarvitse tietää toisistaan mitään muuta kuintakaisinkutsu- ja rekisteröintirajapinnat (perustelu).

ATAMin ATAMin vaiheet (2 päiväinen)vaiheet (2 päiväinen)

1. päivä

2. päivä

0. Ennakkovalmistelu1. ATAMin esittely2. Liiketoiminnan asettamat vaatimukset tuotteelle3. Arkkitehtuuriesittely4. Arkkitehtuurilähestymistapojen tunnistaminen5. Laatupuun ja skenaarioiden laadinta6. Arkkitehtuurilähestymistapojen analysointi7. Skenaarioaivoriihi ja priorisointi8. Arkkitehtuurilähestymistapojen analysointi9. Tulosten esittäminen

OsallistujatOsallistujat

Sidosryhmät:

• Arkkitehti• Ylläpitäjä• Testaaja• Standardiasiantuntija• Turvallisuusvastaava• Projektipäällikkö• Tuotepäällikkö• Asiakas• Loppukäyttäjä• Oheispalveluvastaava• Sovellusalueen asiantuntija• Laiteasiantuntija• Huolto• Markkinointi• Ohjelmistokehittäjä

1. päivä3-5 hlöä. Arkkitehti ja muista kiinteästi suunnittelussa tai toteutuksessa mukana olleitaArviointiryhmä

2. päivä5-10 hlöä. Kattavasti kaikkien sidosryhmien edustajiaArviointiryhmä

ATAM prosessiATAM prosessiPäivä 1

ATAMin esittely• ATAMin vaiheet• ATAMin tekniikat (skenaariot, laatupuu, jne)

Liiketoimintanäkökulma• tärkeimmät toiminnallisuudet käyttäjien kannalta• liiketoimintatavoitteet• taloudelliset, poliittiset yms. rajoitteet

Arkkitehtuuriesittely• tekniset rajoitteet (kj, ohjelmistoalustat, laitteisto jne.)• järjestelmän ulkoiset rajapinnat• arkkitehtuurin kuvaus

Päivä 1 jatkuu

Arkkitehtuuriratkaisujen tunnistaminen• tunnistetaan ja nimetään käytetyt tyylit, suunnittelumallit ja omat ratkaisut• selitetään miten ratkaisuilla oletetaan saavutettavan tietyt laatuvaatimukset

Laatupuun ja skenaarioiden laatiminen• tarkennetaan laatuvaatimukset järjestelmäkohtaisella ryhmittelyllä• konkretisoidaan kukin tarkennettu laatuvaatimus skenaariolla• priorisoidaan skenaariot tärkeyden ja vaikeuden perusteella

Arkkitehtuuriratkaisujen analysointi • keskitytään tärkeimpiin skenaarioihin• kysytään: tekeekö tämä arkkitehtuuri mahdolliseksi skenaarion, miksi? • arkkitehtuuri on syyllinen kunnes toisin todistetaan• pyritään tunnistamaan riskit, turvalliset ratkaisut, herkkyyskohdat ja tasapainokohdat

Täydennys (Päivä 2))Täydennys (Päivä 2))

Skenaarioaivoriihi • kaikki osapuolet esittävät skenaarioita omilta näkökulmiltaan• uudet skenaariot priorisoidaan ja liitetään laatupuuhun• vanhat skenaariot vahvistetaan

Uusinta-analyysi • tärkeimmät skenaariot tarkistetaan vasten arkkitehtuuria• mahdolliset uudet riskit tunnistetaan

RaportointiRaportointi

ATAM:in tärkeimmät tulokset:

• Keskeisten arkkitehtuuriratkaisujen tunnistaminen• Olennaisimpien laatuun vaikuttavien käyttö- ja

kehitysskenaarioiden tunnistaminen• Laatupuu skenaarioineen: kuvaus laatuvaatimusten ja

arkkitehtuuriratkaisujen yhteydestä• Arkkitehtuuriin liittyvien riskien tunnistaminen

Raportin rakenne (esimerkiksi)Raportin rakenne (esimerkiksi)

1. Introduction2. Target System

2.1 Description of the System2.2 Most Important Architectural Solutions

3. Analyzed Scenarios3.1 Maintainability3.2 Reliability 3.3 Efficiency 3.4 Usability

4. Analysis Overview4.1 General Observations4.2 Specific Issues4.3 About the Process

5. ConclusionsReferences Appendix: Complete Scenario List

ArviointiraporttiArviointiraportti

Tyypillisesti 10-15 korkealle priorisoitua skenaariota

Skenaarioon liittyvät arkkitehtuuriratkaisut tunnistetaan ja luokitellaan (esim. T = tasapainokohta, R = riski, N = ei-riski)

Arkkitehdin selvitys skenaarion hoitumisesta kirjataan (Description)

Kunkin ratkaisun liittyminen skenaarioon selitetään (Argumentation)

Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ...ohar/luennot/luennot2009/Ohar9...

Documents

1234 Menetelmä ja kilttilä

Semanttisen yhteentoimivuuden viitekehys (menetelmä)

LEAN-MENETELMÄ SUOMALAISESSA … · Käytettävissä olevien tutkimustulosten ja käytännön kokemusten perusteella Lean-menetelmä sopii erinomaisesti prosessiluonteisen toiminnan

Menetelmä avoimen maastotiedon vaikuttavuuden arvioimiseksi...Menetelmä avoimen maastotiedon vaikuttavuuden arvioimiseksi Tutkimusraportti 30.4.2014 Aalto-yliopisto, Maankäyttötieteiden

Ohjelmistoarkkitehtuurit Kevät 2016, luento 3 Arkkitehtuurin …ohar/materiaali2016/luento03_kuvaus.pdf · 2016-01-20 · Arkkitehtuurin kuvaamisesta • Wanha vitsi(?) Mies lentää

Talent Base KAPO-menetelmä

Nikkilän Kulttuurikäytävät & Cultural planning -menetelmä työkaluna

KYMENLAAKSON AMMATTIKORKEAKOULU Ohjelmistotekniikka

Komponenttipohjainen ohjelmistotekniikka (TJTSS56) Osa 6

Johdatus Kuvastin-menetelmään - Reflektiivinen itse- ja vertaisarvioinnin menetelmä sosiaalityössä

1 Ohjelmistotekniikka johdanto Kevät 2003 Hanna-Kaisa Lammi LTKK/Tite

Ohjelmistoarkkitehtuurit, TTY Vierailuluentoohar/luennot_materiaali/ohar2014_siikarla.pdf · » Git, SVN, Jenkins, Bamboo, JIRA, Trac Mm. näillä teknologioilla. Bitwise etsii ihmisiä,

Ristiinvalidointi ja bootstrap-menetelmä 20.10.2010

ITIMS53 Menetelmä Draw the Experience

Ohjelmistoarkkitehtuurit, TTY Vierailuluentoohar/luennot/luennot2012/ohar 2012... · 2013-01-31 · Bitwiserit hoitavat projektit, joihin kukaan muu pysty • haasteita • mielenkiintoisia

Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ...ohar/luennot/luennot2010/Ohar9 Arviointi1.pdf · Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 9

Ohjelmistoarkkitehtuurit Kevät 2016 Komponenttien ...ohar/materiaali2016/luento05_vuorovaikutus.pdf · – Voi joko suorittaa palvelut ja palauttaa tuloksen asiakkaalle tai toimia

Arkkitehtuurin mallintaminen - University of Helsinki · – 3D-mallien käyttö rakennusten suunnittelun apuna! 25.9.2014 581385 Ohjelmistoarkkitehtuurit 5 Kommutatiivinen kaavio

Ennakkoarviointi -menetelmä, ihmisiin kohdistuvien vaikutusten arviointi (IVA+)

010758000 Ohjelmistotekniikka - Yrityksen l aatujärjestelmät ja mittarit