ATAM-menetelmän soveltaminen pienprojekteissa

Kokoteksti

(1)REIMA PIILILÄ ATAM-MENETELMÄN SOVELTAMINEN PIENPROJEKTEISSA Diplomityö. Tarkastaja: professori Hannu-Matti Järvinen Tarkastaja ja aihe hyväksytty Tieto- ja sähkötekniikan tiedekuntaneuvoston kokouksessa 5. joulukuuta 2012.

(2) i. TIIVISTELMÄ PIILILÄ, REIMA: ATAM-menetelmän soveltaminen pienprojekteissa Tampereen teknillinen yliopisto Diplomityö, 70 sivua, 0 liitesivua Helmikuu 2016 Signaalinkäsittelyn ja tietoliikennetekniikan diplomi-insinöörin tutkinto-ohjelma Pääaine: Sulautetut järjestelmät Tarkastaja: professori Hannu-Matti Järvinen Avainsanat: ATAM, arkkitehtuurianalyysi, ohjelmistoarkkitehtuuri, pienprojekti, soveltaminen Ohjelmistoarkkitehtuurin analysointi on toimenpide, millä pyritään löytämään arkkitehtuurista riskejä, jotka voivat realisoitua joko kehitysvaiheessa tai valmiin ohjelmiston normaalissa käytössä. Riskien kartoittamisella pyritään saavuttamaan mm. säästöjä projektin kustannuksissa. Arkkitehtuurin analysointiin löytyy lukuisia eri menetelmiä, joista tämän työn puitteissa keskitytään vain ATAM-menetelmään. ATAM on muihin menetelmiin verrattuna raskas – pääosin miestyötuntien perusteella – ja sopii siten parhaiten isokokoisiin projekteihin. Tämän työn tarkoituksena on keventää ATAM-menetelmää siten, että se soveltuisi kustannuksiltaan myös pienprojektien käyttöön. Tässä työssä on sovellettu ATAM-menetelmää arkkitehtuuriin, mikä on piirteiltään modulaarinen ja varioitava. Arkkitehtuurin pohjalta on ennen analyysiä julkaistu jo kaksi valmista tuotetta, jolloin ilmeisimmät puutteet ovat jo korjattu. Projektin kehitystiimin koko on supistunut kahteen aktiiviseen kehittäjään, mikä on ATAMmenetelmän laajuuden kannalta hyvin pieni projekti. Arkkitehtuurin riskien kartoituksen ohessa on pyritty kartoittamaan ATAM-menetelmän muunneltavuutta ja sen soveltuvuutta pienessä mittakaavassa. Työssä on esitetty ATAM-menetelmän kaikki työvaiheet suppeasti, sekä muutokset, mitä menetelmään on tehty. Muunnelmassa on pyritty supistamaan menetelmää pienemmän projektin skaalaan siten, että analyysin arvioitu kustannustehokkuus ei kärsisi. Työstä käy ilmi, että menetelmään soveltaminen on osittain tilannekohtaista, mikä riippuu paljolti käytettävissä olevista resursseista, resurssien tietotaidosta ja menetelmän keventämistarpeesta. Käytäntöön soveltaminen osoitti, että menetelmä on suhteellisen helposti kevennettävissä, mutta pienprojektin ja arkkitehtuurin tila vaikuttavat paljon analyysin luonteeseen ja siitä saataviin tuloksiin. Valmiin tuotteen analysointi poikkeaa suuresti tekemättömän arkkitehtuurin analyysistä..

(3) ii. ABSTRACT PIILILÄ, REIMA: Application of ATAM-method in small scale projects. Tampere university of technology Master of Science Thesis, 70 pages, 0 Appendix pages February 2016 Master’s Degree programme in Signal Processing and Communications Engineering Major: Embedded Systems Examiner: Professor Hannu-Matti Järvinen Keywords: ATAM, architecture analysis, software architecture, small scale project, modification Software architecture analysis is a task, which is used to find risks from the architecture. These risks might become real obstacles during development or during normal operation of a ready product. The reason why risks are tried to be found is to get savings in overall costs of the project. There are multiple methods for architecture analysis however this thesis concentrates only on ATAM-method. ATAM is quite laborious compared to other methods and is therefore best suited for large scale projects. The purpose of this thesis is to modify ATAM-method into a bit lighter form so that it would be better suited for small scale projects. ATAM-method is used in this thesis for analyzing an architecture which is both modular and which can be varied into multiple different products. Before the analysis was done, two different products had been developed from this architecture. Most of the problems in the architecture had been solved during that time. The active development team had been reduced to only two members, which makes this quite a small project compared to the regular size of the projects analyzed with ATAM-method. While trying to map out risks from the architecture, ATAM-method was being evaluated for its modifiability and suitability for small scale projects. This thesis goes through all tasks and phases of ATAM-method briefly and the modifications done to the method. The modification tries to reduce the amount of work needed for full evaluation so that it suits better for small scale projects. Cost-efficiency is also taken into consideration while these modifications are done. It becomes clear from this thesis that modification must be done based on available resources and people’s skills and how much the costs need to be reduced. Practical application showed that this method is relatively easy to modify however the state of the project and architecture affects greatly on the results of the analysis. There is a great difference in analyzing an already finished product compared to an unfinished one..

(4) iii. ALKUSANAT Tämä diplomityö on tehty Symbiolle vuosina 2012 – 2016. Työssä tarkastellaan ATAM-menetelmän muunneltavuutta pienprojektin käyttöön ja käytetään muunneltua menetelmää valmiin arkkitehtuurin analysoimisessa. Haluan kiittää työkavereitani, jotka osallistuvat arkkitehtuurin evaluointiin. Ilman heitä tätä diplomityötä ei olisi voinut tehdä. Kiitos myös kollegoilleni Ari Hyttiselle ja Kai Tusalle oikolukemisesta ja kannustavista puheista. Haluan kiittää myös professori Hannu-Matti Järvistä tämän työn aiheen keksimisestä sekä asiantuntevasta ohjauksesta. Kiitos myös sukulaisille pitkämielisyydestä ja kannustamisesta. Tampere, 15.2.2016.

(5) iv. SISÄLLYS 1 Johdanto................................................................................................................ 1 2 Arkkitehtuurien analysointi ja ATAM-menetelmä ................................................. 2 2.1 Arkkitehtuurien analysointi ...................................................................... 2 2.2 ATAM analyysin suoritus ........................................................................ 3 2.2.1 Analyysiin osallistujat ja niiden roolit ............................................ 3 2.2.2 Laatuominaisuudet, laatupuu ja skenaariot ..................................... 5 2.2.3 Herkkyyskohdat, tasapainokohdat ja riskit .................................... 7 2.2.4 Analyysin toimenpiteet .................................................................. 8 2.2.5 Analyysin jako neljään vaiheeseen ............................................... 11 2.3 ATAM-menetelmän tulokset ja sivutuotteet ........................................... 13 2.4 Analysoinnin edut ja kustannukset ......................................................... 14 2.5 Muut evaluointimenetelmät ................................................................... 15 2.6 Yhteenveto ............................................................................................ 16 3 Analysoitava ohjelmisto ...................................................................................... 17 3.1 Analysoitava ohjelmisto ja sen tehtävät .................................................. 17 3.2 Arkkitehtuurisuunnittelua ohjaavat vaatimukset ja ominaisuudet ........... 18 3.2.1 Yleiset vaatimukset ja laatuominaisuudet ..................................... 18 3.2.2 Liiketoimintanäkökulmat ............................................................. 19 3.3 Arkkitehtuurin kuvaus ........................................................................... 20 3.3.1 Yleiskuvaus ................................................................................. 21 3.3.2 Laitetason näkymä ....................................................................... 22 3.3.3 Moduulit ...................................................................................... 24 3.3.4 Arkkitehtuuri kokonaisuutena ...................................................... 27 3.3.5 Vahtikoira .................................................................................... 30 3.3.6 Datan virtaus arkkitehtuurissa ...................................................... 31 3.4 Varioinnin vaikutus arkkitehtuuriin ........................................................ 33 3.5 Arkkitehtuurin tuomat haasteet .............................................................. 35 4 ATAM-menetelmän soveltaminen ja tulokset ...................................................... 37 4.1 ATAM-menetelmän modifikaatio .......................................................... 37 4.2 Työn kulku ............................................................................................ 38 4.2.1 Suoritus ....................................................................................... 38 4.2.2 Yleiset haasteet ............................................................................ 40 4.2.3 Arvio onnistumisesta ................................................................... 41 4.3 Laatupuu................................................................................................ 42 4.4 Skenaariot .............................................................................................. 43 4.4.1 Skenaario 1 – Käyttöliittymän datojen peilaus ............................. 44 4.4.2 Skenaario 2 – Viestitulva CAN-väylästä ...................................... 49 4.5 Riskit ja riskiteemat ............................................................................... 54 5 Arviot ja jatkokehitys .......................................................................................... 55 5.1 Ohjelmiston tila vuosi analyysin jälkeen ................................................ 55.

(6) v 5.2 Arkkitehtuurin sopivuus vaadittuun tehtävään ........................................ 56 5.3 ATAM-menetelmän arviointi ................................................................. 57 5.4 Hyödyn suhde kustannuksiin ................................................................. 58 6 Yhteenveto .......................................................................................................... 60 Lähteet ................................................................................................................... 62.

(7) vi. TERMIT JA NIIDEN MÄÄRITELMÄT Application layer ATAM AT&T BitBake. CAN Data Provider layer Debian ISO Konfigurointi MySQL OSI-malli Presentation layer QAW QML Rugged Computer SEI SAE J1939 SQLite. UI Variointi. Analysoitavan arkkitehtuurin keskimmäinen kerros, ohjelmalogiikkakerros Architecture Tradeoff Analysis Method, arkkitehtuurin evaluointimenetelmä. Amerikkalainen televiestintäyritys Käännösohjelma, mikä kääntää käännösreseptien perusteella ohjelman ja asennettavan Linuxkäyttöjärjestelmän. Soveltuu erityisesti hyvin pienikokoisten käyttöjärjestelmien kääntämiseen. Controller Area Network. Erityisesti ajoneuvoissa ja teollisuudessa paljon käytetty dataväylä. Analysoitavan arkkitehtuurin alin kerros, tietolähdekerros Linux-jakelu, minkä päälle moni tunnettu Linux-jakelu on rakennettu. International Organization for Standardization, standardisoimisjärjestö Ohjelman toiminnan määrittely koodin ulkopuolisilla konfiguraatiotiedostoilla. Laajasti käytetty palvelimellinen transaktiotietokanta. Open Systems Interconnection Reference Model, tiedonsiirtoprotokollien yhdistelmää kuvaava malli. Analysoitavan arkkitehtuurin ylin kerros, käyttöliittymäkerros. Quality Attribute Workshop, ATAM-menetelmää tukeva analysointimenetelmä. Qt Meta Language tai Qt Modeling Language. Deklaratiivinen käyttöliittymän määrittelykieli. Tavallista kestävämmällä rakenteella suunniteltu tietokone. Carnegie Mellon University, Software Engineering Institute. ATAM-menetelmän kehittänyt instituutti. CAN-väylästandardi, mitä käytetään laajasti autoteollisuudessa. Avoimena lähdekoodina levytyksessä oleva kevyt palvelimeton transaktiotietokanta, jonka tekijänoikeuksista on luovuttu. User Interface, käyttöliittymä. Uuden toisista tuotteista eroavan tuotekonfiguraation tekeminen käyttäen tuotteille yhteisiä ydinkomponentteja. Varioidussa tuotteissa voi olla toisistaan poikkeavia moduuleja ja moduulien konfigurointi voi erota..

(8) vii XML. Extensible Markup Language, tallennusformaatti..

(9) 1. 1. JOHDANTO. Ohjelmistojen noudattaa usein kaavaa, missä määritellään ja suunnitellaan, toteutetaan ja korjataan toteutusta. Joskus tuote voi valmistua pienelläkin työllä, mutta toisinaan ohjelmiston kehityksen, testauksen tai käyttöönoton myötä ohjelmiston korjaustarve voi olla kustannuksiltaan huomattavan suuri. Tuotekehityksen vaiheisiin on kehitetty useita arkkitehtuurin analyysitekniikoita, millä pyritään löytämään riskejä ennen niiden realisoitumista ja siten ohjaamaan tuotekehitystä parempaan suuntaan. Tämän diplomityön puitteissa tutkitaan yhden arkkitehtuurien analysointitekniikan – ATAM-menetelmän – toimivuutta pienikokoisen projektin puitteissa. ATAM-menetelmä on ohjeelliselta rakenteeltaan raskas, eikä sen täysimittainen suoritus ole kustannustehokasta hyvin pienikokoisten projektien tapauksessa. Luvussa 2 esitellään ATAM-menetelmä sellaisena, miten se on tarkoitettu suoritettavan arkkitehtuurien analyysissä. Myöhemmin luvussa 4 esitellään modifioitu version ATAM-menetelmästä, missä on pyritty supistamaan kustannuksia menettämättä liikaa menetelmän tulosten tarkkuutta. Tätä on pyritty saavuttamaan supistamalla tai poistamalla hyötysuhteeltaan heikompia työvaiheita ja analyysiin osallistujia, samalla kun tärkeimmät työvaiheet on pyritty säilyttämään ennallaan. Luvussa 3 on esitelty arkkitehtuuri sillä tarkkuudella, mikä on nähty luvun 4 (ATAM-menetelmän soveltaminen ja tulokset) ymmärtämisen kannalta tarpeelliseksi ja riittäväksi. Kuvattua arkkitehtuuria on kehitetty kohtuullisen paljon, joten se ei vastaa aivan pienimpien projektien kokoluokkaa. Arkkitehtuuriin liittyy paljon yksityiskohtia ja tarkempi kuvaus vaatisi huomattavasti enemmän dokumentointia, kuin mitä tähän diplomityöhön on mahdollista sisällyttää. Siitä johtuen arkkitehtuuriluvusta on supistettu tämän diplomityön kannalta epäoleelliset asiat pois. Ensimmäiset luvut, luvut 2-4 on kirjoitettu samalla, kuin arkkitehtuurin analyysiä on tehty. Luku 5 (Arviot ja jatkokehitys) on kirjoitettu vuosi työvaiheen jälkeen, jolloin analyysin perusteella tehdyt jatkokehityshankkeet ovat jo osittain realisoituneet. Vuoden tauon myötä analyysin tuloksien ja siitä saatuja hyötyjen tarkastelu on hieman realistisempaa, sillä tuotteen elinkaaren ollessa pitkä, analyysin tulokset voivat vaikuttaa pitkälle tulevaisuuteen. Luvun 5 sisältö kattaa arkkitehtuurille tehdyt jatkotoimenpiteet ja arkkitehtuurin arvioinnin, sekä ATAM-menetelmän arvioinnin ja kustannuksista saatuja hyötyjä..

(10) 2. 2. ARKKITEHTUURIEN ANALYSOINTI JA ATAM-MENETELMÄ. Tässä luvussa käsitellään arkkitehtuurien analysointia, niihin liittyviä menetelmiä, etuja ja kustannuksia. Pääpainona on kuitenkin käydä läpi ATAM-menetelmän teoria, joka on käsitelty aliluvussa 2.2. Teoria on esitetty hyvin kompaktisti suhteessa siihen, että ATAM-menetelmän kehittänyt SEI (Carnegie Mellon University, Software Engineering Institute) on kirjoittanut aiheesta useamman kirjan ja lukuisia julkaisuja. Muissa luvuissa käsitellään evaluointia hieman yleisemmin.. 2.1. Arkkitehtuurien analysointi. Ennen kuin arkkitehtuuria voidaan analysoida on selvitettävä, mitä ohjelmistorakkitehtuurilla ylipäätään tarkoitetaan. Arkkitehtuurille löytyy eri lähteistä kymmeniä toisistaan poikkeavia määritelmiä, mikä osoittaa, että arkkitehtuurin määritelmä ei ole täysin yksiselitteinen [1]. Yhteistä määritelmillä on kuitenkin se, että arkkitehtuuri on järjestelmän rakenteen sekä toiminnan määritelmä ja se pyritään kuvaamaan eri lähestymistavoilla. Arkkitehtuuri siis kuvaa, mistä osista järjestelmä koostuu, mitkä ovat niiden suhteet ja miten osat toimivat keskenään. Arkkitehtuuri kattaa sekä staattiset käännösaikaiset rakenteet että ajoaikaiset dynaamiset rakenteet. [4] Koska arkkitehtuuri on järjestelmän tai järjestelmien abstraktio, jonka määritelmät ohjaavat toteutusta, sen merkitys on lopputuotteen onnistumisen kannalta erittäin suuri. Onnistumiseen vaaditaan, että arkkitehtuuri vastaa sille asetettuihin rajoitteisiin ja vaatimuksiin ja että se on ylipäätään toteutettavissa. Järjestelmää suunnitellessa kaikki vaatimukset eivät välttämättä ole tulleet vielä julki, sen lisäksi valituissa suunnitteluratkaisuissa voi piillä riskejä, joita ei ole otettu huomioon. Mikäli riskejä ja määrittelemättömiä vaatimuksia ei löydetä projektin alkuvaiheessa, tarvittavien korjaavien muutosten tekeminen voi tulla projektin loppuvaiheessa kohtuuttoman kalliiksi. Näiden riskien ja vaatimusten kartoittamiseen on kehitetty useita eri analysointimetodeja, josta yksi on ATAM. Mikäli analyysi tehdään hyvin varhaisessa vaiheessa, arkkitehtuurillisilla muutoksilla voidaan välttyä ainakin osalta analyysissä ilmenneiltä riskeiltä. Toisaalta analyysillä saadaan selville voiko esitetyllä arkkitehtuurilla ylipäätään saavuttaa sille asetettuja laatuvaatimuksia. [1] Arkkitehtuurin voi analysoida missä vaiheessa tahansa, kunhan järjestelmästä on olemassa riittävän tarkka kuvaus. Analyysi ajoitetaan useimmiten joko projektin alkuvaiheeseen, jolloin arkkitehtuuriin voi vielä tehdä muutoksia, tai implementoinnin päättymisen jälkeen, jolloin analyysin tuloksia voidaan hyödyntää järjestelmän jatkokehityksessä. Hyödyllisin hetki suorittaa analyysi on tietysti projektin alussa siinä vaiheessa, kun arkkitehtuuri on suunniteltu, mahdollisesti ennen kuin vaatimukset on.

(11) 3 jäädytetty. Alkuvaiheessa tehdyn analyysin tuloksena voi parhaimmassa tapauksessa tehdä muutokset sekä vaatimuksiin että arkkitehtuuriin siten, että hankalimmat yllätykset saadaan karsittua pois. [1] Analyysin hyödyt eivät rajoitu pelkästään riskinhallinnallisiin seikkoihin, vaan analyysimetodista riippuen prosessin suorittaminen tuottaa usein sivutuotteita. Evaluoinnin esivaatimukset pakottavat arkkitehtiä selventämään arkkitehtuurin kuvausta ja parantamaan dokumentaation laatua. Prosessin aikana vuorovaikutus asiakkaan kanssa paranee ja vaatimukset selkenevät. Lisäksi tieto leviää organisaation sisällä ja voi tulla ilmi komponenttien uudelleenkäytettävyysmahdollisuuksia projektien välillä. ATAM-mallin mukaisen analyysin lopputuotteet käsitellään aliluvussa 2.3. [1] On ilmeistä, että järjestelmän analysointi ei ole ilmaista, vaan se vaatii jonkinlaisen ajallisen panostuksen. Menetelmästä riippuen evaluointi voi olla esimerkiksi lyhyt tarkistuslistan läpikäynti, kokeellinen prototyyppiarkkitehtuurin testaus tai isohko monta ihmista yhteen kokoava prosessi. ATAM lukeutuu näistä viimeiseen, ollen siten oppikirjanmukaisesti suoritettuna suhteellisen kallis menetelmä. Menetelmistä voi yleisesti sanoa sen, että kevyellä menetelmällä saa löydettyä ja siivottua kaikkein ilmeisimmät riskit, kun taas vaikeammin löydettävien, potentiaalisesti yhtä suurien riskien löytämiseen tarvitaan perusteellisempaa menetelmää. ATAM-menetelmä pyrkii perusteelliseen evaluointiin ottamalla mukaan näkemyksiä mahdollisimman monipuolisesti, mutta samaan aikaan olemalla kompakti prosessi, joka ei vie osallistujilta paljon kalenteriaikaa.. 2.2. ATAM analyysin suoritus. ATAM-pohjainen arkkitehtuurin analyysi on kuvattu kirjallisuudessa hyvin tarkkaan ja siitä on olemassa paljon materiaalia. Tässä aliluvussa käy ilmi, että ATAM on luonteeltaan skenaariopohjainen ja analyysissä lähestytään arkkitehtuuria laatuvaatimuksien näkökulmasta. Tämän luvun sisällössä käsitellään analyysiin tarvittavat osallistujat (aliluku 2.2.1), evaluoinnin työvaiheita tukeva pohjateoria (aliluku 2.2.2), evaluoinnin jako toimenpiteisiin (aliluku 2.2.4) ja toimenpiteiden jako vaiheisiin (aliluku 2.2.5). 2.2.1. Analyysiin osallistujat ja niiden roolit. ATAM-analyysiin osallistuvat ryhmät ja niiden vastuut evaluoinnissa on kirjallisuudessa melko tarkkaan määritelty, mutta ryhmien tarkempi kokoonpano on jätetty analyysin tekijöiden päätettäväksi. Osallistujat jakautuvat karkeasti kolmeen ryhmään, joista ensimmäinen on analyysiä johtava ja prosessin kulkua tarkkaileva evaluointitiimi. Toinen ryhmä koostuu projektin päättäjistä, jotka tuntevat järjestelmän ja joilla on valta tehdä arkkitehtuurillisia päätöksiä. Viimeinen ryhmä koostuu muista sidosryhmistä, joihin lukeutuvat mm. loppukäyttäjä tai ylläpitäjä. He tuovat omat käytännönläheiset näkemyksensä järjestelmälle asetettavista vaatimuksista. Kuva 1 esittelee evaluointiin osallistuvat ryhmät ja niiden ohjeelliset koot..

(12) 4. Projektin päättäjät (2-5 henk: projektipäällikkö, arkkitehti, asiakas..). Evaluaatiotiimi (2-5 henk). Arkkitehtuuri Arkkitehtuuri. Sidosryhmät (ylläpitäjä, markkinoija, tuotepäällikkö, testaaja, loppukäyttäjä..). Kuva 1 Evaluointiin osallistuvat ryhmät. Evaluointitiimin merkitystä analyysissä ei voi korostaa liikaa. Tiimin harteilla on ohjata analyysi ATAM-mallin määrittelemän prosessin mukaisesti ja tuoda mukaan oma laaja arkkitehtuurillinen kokemuksensa, kun arkkitehtuurillisia suunnitteluratkaisuja analysoidaan. Kirjallisuus esittää tiimin jäsenille tarkkaa roolijakoa, jossa jäsenille annetaan tietyt ennaltamääritellyt vastuut analyysin kulun ajaksi. Näitä vastuita on tiiminjohtaja, evaluoinninjohtaja, kirjuri, ajan tarkkailija, prosessin tarkkailija, prosessiin pakottaja ja kyselijä. Kukin evaluoija voi saada useamman vastuun samanaikaisesti ja toisaalta useampi evaluoija voi jakaa samoja vastuita keskenään. Evaluoinnin onnistumisen kannalta tärkeintä on kuitenkin se, että evaluoijat ovat kokeneita arkkitehtejä ja osaavat tunnistaa arkkitehtuurin suunnitteluratkaisuista niissä piilevät riskit. [2] Projektin päättäjät on ryhmä, joka vastaa järjestelmästä ja jolla on valta tehdä arkkitehtuurillisia päätöksiä. Tärkeimmät osakkaat ryhmässä ovat projektipäällikkö, arkkitehti ja asiakas. Projektin päättäjät tuntevat järjestelmän ja siten osaavat sekä esitellä sen että vastata evaluointitiimin tekemiin kysymyksiin. Arkkitehdin läsnäolo on kaikkein tärkein, sillä järjestelmää ja sen arkkitehtuuria tulee selittää koko prosessin keston ajan. Asiakkaan tärkeimpiin tehtäviin lukeutuu järjestelmälle asetettujen vaatimuksien selvittäminen ja tarvittaessa ristiriitaisten vaatimusten muuttaminen. [2] Viimeisenä ryhmänä analyysiin kutsutaan muut sidosryhmät, joilla on intressejä arkkitehtuurin suhteen ja joiden läsnäolo nähdään tarpeellisena. Sidosryhmiin lasketaan kaikki, jotka liittyvät jollain tavalla järjestelmään ja siten tuovat henkilökohtaisen näkemyksensä, mitä he vaativat järjestelmältä. Sidosryhmistä mm. loppukäyttäjä tuo näkemyksensä, miten hän järjestelmää käyttäisi, kun taas ylläpitäjä tuo näkemyksensä ylläpitoseikoista. Sidosryhmät osallistuvat analyysiin vasta loppuvaiheessa ja prosessin puolivälissä tehdään päätös, ketkä sidosryhmistä kutsutaan analyysiin mukaan. Analyysiin osallistujien kokoonpano vaihtelee analyysin vaiheesta riippuen ja siitä, millä mittakaavalla analyysi halutaan suoritettavan. Pienimmillään analyysi suoritetaan muutaman henkilön voimin, kun taas suuremman mittakaavan analyysiin osallistuu yli kymmenen henkilöä. Tärkeintä on kuitenkin saada pöydän ympärille ne henkilöt, joilla on analyysiin eniten annettavaa ja joiden avulla analyysiin käytetystä ajasta saadaan.

(13) 5 eniten irti. Mikäli analyysiin ei saada oikeita henkilöitä tai ryhmät jäävät liian pieniksi, on riski, että arkkitehtuurista jää huomaamatta vakavia riskitekijöitä. Taulukko 1 esittää evaluointiin osallistujien ajallisen käytön rakenteen täysimittaisessa ATAMmenetelmässä. Taulukossa mainitut vaiheet käsitellään aliluvussa 2.2.5. [2] Taulukko 1 Täysimittaisen ATAM-menetelmän osallistujien ajalliset panostukset [1]. Vaihe. Evaluointitiimi (oletetaan 5 henkilöä). Projektin päättäjät (arkkitehti, asiakas ja projektipällikkö). Muut sidosryhmät (oletetaan 8 henkilöä). Vaihe 0: valmistelu. 1 päivä (tiiminjohtaja). 1 päivä. 0. Vaihe 1: ensimmäinen evaluointi (1 päivä). 5 päivää. 3 päivää. 0. Vaihe 2: Täysi 15 päivää evaluointi (3 päivää). 9 päivää + 2 päivää valmisteluun. 16 päivää. Vaihe 3: Loppuvaihe. 15 päivää. 3 päivää lukea ja vastata raporttiin. 0. Summa. 36 miestyöpäivää. 18 miestyöpäivää. 16 miestyöpäivää. 2.2.2. Laatuominaisuudet, laatupuu ja skenaariot. ATAM-pohjaisessa analyysissä arkkitehtuuria lähetään tutkimaan siltä vaadittuja laadullisia ominaisuuksia vastaan. Analyysin tekeminen vaatii, että yksittäiset laatuominaisuudet pitää pystyä tunnistamaan ja erottamaan toisistaan. ISO-standardi (International Organization for Standardization) määrittelee kahdeksan laatuominaisuutta, joista kukin koostuu pienemmistä osista, laatualiominaisuuksista. Kuva 2 esittää standardin määrittelemät laatuominaisuudet, joista luotettavuus on jaettu edelleen aliominaisuuksiinsa. ATAM-menetelmässä ei kuitenkaan tarvitse noudattaa ISO-standardin määrittelemiä laatuominaisuuksia orjallisesti, vaan niistä voi käyttää synonyymejä sovellettavan alan käsitteistöstä tai yhdistelmiä tilanteen salliessa..

(14) 6. Toiminnallinen sopivuus. Suorituskyky. Yhteensopivuus. ISO/IEC FCD 25010. Turvallisuus. Maturiteetti Saatavuus. Luotettavuus Vikasietoisuus Ylläpidettävyys. Käytettävyys. Toipuminen. Siirreltävyys. Kuva 2 Ote ISO/IEC FCD 25010 laatukehikosta [3]. Analyysin yksi tärkeimmistä työkaluista on laatupuu (kuva 3). Laatupuu on nelitasoinen puurakenne, jonka juurena on Laatu. Laatupuun juureen yhdistyvä toinen taso kokoaa vaaditut laatuominaisuudet, joista kukin käsitellään erikseen. Laatuominaisuuksina on suositeltavaa käyttää ISO-standardin laatukehikon (kuva 2) määrittelemiä laatuominaisuuksia, mutta tarpeen mukaan standardin laatukehikon kategorioista voi joustaa. Laatuominaisuudet tarkennetaan vaatimuskategorioilla, jotta selviää miksi kyseistä laatuominaisuutta järjestelmältä vaaditaan. Tarkennuksista laaditaan erilaisia skenaarioita, joita käyttäen järjestelmä voidaan testata ja joissa laatuvaatimukset realisoituvat. Skenaariot arvioidaan karkeasti asteikolla: high (H), medium (M), low (L). Kuva 3 esittää pienen osan täytetystä laatupuusta, jossa skenaariot ovat viimeisen tason lehtinä. Kuvan skenaarioon on annettu kaksi arvoa: Ensimmäinen arvo kertoo kuinka tärkeä skenaario on ja toinen kuinka vaikea se on implementoida tai muuten toteuttaa. Laatuominaisuudet Laatuominaisuudet. Tarkennukset Tarkennukset. Skenaariot Skenaariot. Datan Datan latenssi latenssi. (H,L) (H,L). Viestien Viestien pitää pitää edetä edetä järjestelmän järjestelmän läpi läpi käyttöliittymälle käyttöliittymälle 200ms 200ms sisällä sisällä. Transaktioiden Transaktioiden käsittelykyky käsittelykyky. (M,M) (M,M). Tietokannan Tietokannan pitää pitää pystyä pystyä suorittamaan suorittamaan 100 100 transaktiota transaktiota minuutissa minuutissa. (H,M) (H,M). Vaihda Vaihda sqlite sqlite tietokanta tietokanta MySQL MySQL kantaan kantaan alle alle 44 viikossa viikossa. (M,H) (M,H). Lisää Lisää uusi uusi tietokantapalvelin tietokantapalvelin järjestelmään järjestelmään alle alle 22 viikossa viikossa. Suorituskyky Suorituskyky. Uusi Uusi laskentamoduuli laskentamoduuli Laatu Laatu. Muunneltavuus Muunneltavuus Tietokannan Tietokannan vaihto vaihto. Käytettävyys Käytettävyys. Kuva 3 Osittain täytetty laatupuu. Laatupuun skenaariot käsitellään yksitellen ja ne ovat tärkeimmät työkalut arkkitehtuurin analysoinnissa. Skenaario kuvataan yksinkertaisimmassa tapauksessa rakenteella ympäristö, ärsyke ja odotettu vaste. Skenaarioon listataan kaikki arkkitehtuuriratkaisut, jotka liittyvät kyseiseen skenaarioon. Kukin arkkitehtuuriratkaisu analysoidaan yksitellen ja niiden vaikutus skenaariota vastaavaan laatuominaisuuteen.

(15) 7 käydään tiimin kesken läpi. Kuva 4 esittelee esimerkkiskenaarion tietokannan suorituskyvystä. Skenaarion loppuun merkitään selkokielisesti perustelut suunnitteluratkaisuihin tehdyistä merkinnöistä ja siihen voi mainita myös muut löydökset. Loppuun voi lisätä myös skenaarioon liittyvät arkkitehtuurikuvat, jotka selventävät skenaariota. Skenaario. #S2. Tietokannan tulee pystyä suorittamaan 100 transaktiota minuutissa. Ominaisuus. Suorituskyky. Ympäristö. Normaali toiminta. Ärsyke. Tietokanta saa 100 transaktiota ensimmäisen 10 sekunnin aikana. Vaste. Tietokanta suorittaa kaikki transaktiot 60 sekunnin sisällä. Suunnitteluratkaisu. Herkkyyskohta. Tasapainokohta. Riski. Tietokantoja on yksi. S2. T1. R1. Erillinen tietokantapalvelin. S3. Turvallinen ratkaisu. N1. ... Syyt. * Tietokannan koon kasvaessa suureksi transaktioiden suoritus hidastuu ja koska pyynnöt joudutaan sarjallistamaan, jolloin kannan koolla 100 transaktion suoritus kestää yli 60 sekuntia.. Kuva 4 Esimerkkiskenaario tietokannan suorituskyvystä. Kuhunkin suunnitteluratkaisuun kirjataan merkintä jos niissä nähdään herkkyyskohtia, tasapainokohtia tai riskejä. Toisaalta, mikäli suunnitteluratkaisu nähdään turvallisena ratkaisuna, lisätään jälleen merkintä. Jokainen herkkyyskohta, tasapainokohta, riski ja turvallinen ratkaisu merkitään yksilöllisellä kirjain-numeroyhdistelmällä, jolla löydös kirjataan skenaarion lisäksi erilliseen katalogiin. Esimerkkiskenaarion tapauksessa (kuva 4) herkkyyskohdat on merkitty S-kirjaimella (sensitivity), tasapainokohdat Tkirjaimella (tradeoff), riskit R-kirjaimella (risk) ja turvalliset ratkaisut N-kirjaimella (non-risk). Nämä selvitetään tarkemmin seuraavassa aliluvussa. Mikäli useamman skenaarion piirin on tunnistettu sama suunnitteluratkaisu ja näihin skenaarioihin vaikuttaa esimerkiksi sama riski, kyseinen riski kirjataan kuhunkin skenaarioon samalla yksilöllisellä tunnisteella. [1] 2.2.3. Herkkyyskohdat, tasapainokohdat ja riskit. ATAM-analyysin edetessä arkkitehtuurin tarkempaan tarkasteluun suunnitteluratkaisuista tunnistetaan niin sanottuja herkkyyskohtia, tasapainokohtia ja riskejä. Nämä ovat arkkitehtuurin kohtia, jotka vaikuttavat suoraan järjestelmän laatuominaisuuksiin. Arkkitehti saattaa olla tietoinen näistä arkkitehtuurin ominaisuuksista jo suunnitteluvaiheessa, mutta niistä ei ole välttämättä mainintaa arkkitehtuurin dokumentaatiossa [1]. Herkkyys- ja tasapainokohdat sekä riskit ja turvalliset ratkaisut ovat tärkeitä ATAM-menetelmästä saatavia tuloksia. Arkkitehtuurilliset herkkyyskohdat (engl. sensitivity point) ovat suunnitteluratkaisuja, jotka vaikuttavat yhteen laatuominaisuuteen. Herkkyyskohta on arkkitehtuuriratkaisu, joka on tärkeä jonkin laatuvaatimuksen saavuttamisen kannalta. Esimerkkinä palvelimien määrä vaikuttaa web-palvelun suorituskykyyn ja siten palvelimien.

(16) 8 lukumäärä on herkkyyskohta. Toisaalta salatun yhteyden turvallisuus on ”herkkä” kryptauksessa käytettyyn bittimäärään. Mikäli herkkyyskohtaan vaikutetaan – tässä tapauksessa palvelimien määrää muutetaan tai salauksen bittimäärää muutetaan – muutos vaikuttaa suoraan herkkyyskohtaan liittyvään laatuominaisuuteen. [1][5] Tasapainokohta (engl. tradeoff point) on kuin herkkyyskohta, mutta vaikutettavia laatuominaisuuksia on kaksi tai useampi. Laatuominaisuuksiin kohdistuva vaikutus on ominaisuuksien kesken yleensä vastakkaissuuntainen, mistä tulee nimitys ”tasapainokohta”. Usean palvelimen käyttö web-palvelussa on hyvä esimerkki tasapainokohdasta: palvelimien lisääminen parantaa suorituskykyä ja saatavuutta, mutta joissain useamman palvelimen ratkaisuissa tietoturvallisuus voi heikentyä. Tasapainokohdan negatiiviset laatuvaikutukset saattavat olla järjestelmän vaatimuksien kannalta hyväksyttäviä, mutta niiden tiedostaminen on hyödyllistä mikäli tasapainokohtaan tehdään muutoksia jossain vaiheessa järjestelmän elinkaarta. [5] Arkkitehtuurista löydetyt riskit (engl. risk) ovat arkkitehtuuripäätöksiä, jotka potentiaalisesti estävät halutun laatuominaisuuden saavuttamisen. Esimerkiksi tietokantaa toteutettaessa yhden ohjelmaan integroidun SQLite-tietokannan käyttäminen voidaan nähdä riskinä muunneltavuuden kannalta, mikäli ohjelman rinnalle halutaan lisätä samaa tietokantaa käyttävä selaintuki. Koska SQLite ei perustu tietokantapalvelimen käyttöön, useamman samanaikaisen käyttäjän lisääminen vaatii muutoksia arkkitehtuuriin, mikä voi koitua hyvin ongelmalliseksi. Toisaalta analyysissä voidaan nähdä jokin suunnitteluratkaisu turvallisena ratkaisuna (engl. non-risk), eli ratkaisuna joka edesauttaa jonkin laatuominaisuuden toteuttamista [1]. MySQLtietokantapalvelimen käyttö saatettaisiin nähdä tässä esimerkkitilanteessa turvallisena ratkaisuna. Riskit ovat hyvin tärkeitä arkkitehtuurista saatavia tietoja, joiden löytyminen varhaisessa vaiheessa projektia saattaa johtaa huomattaviin säästöihin projektin kokonaiskustannuksissa. Lisäksi herkkyys- ja tasapainokohtien tunnistaminen on kehityksen kannalta hyödyllistä, sillä implementoinnin tai ylläpidon aikana saattaa tulla tarve tehdä muutoksia näihin järjestelmän kohtiin. Tieto siitä, miten eri arkkitehtuuriratkaisut vaikuttavat eri laatuominaisuuksiin, ohjaa tekemään turvallisempia muutoksia arkkitehtuuriin ja sen eri osiin. 2.2.4. Analyysin toimenpiteet. Analyysi jakautuu yhdeksään selkeästi toisistaan eroteltavaan toimenpiteeseen, jotka suoritetaan järjestyksessä alusta loppuun. Järjestykseen voi tehdä niissä tapauksissa poikkeuksia, kun halutaan siirtyä prosessissa taaksepäin selventämään tai täydentämään jotain aikaisempaa työvaihetta. Rakenne muodostuu karkeasti ilmaistuna toistuvista ratkaisujen esittely ja analysointi –työpareista. Toimenpide 1: ATAM menetelmän esittely. Ensimmäisessä vaiheessa evaluoinnin johtaja esittelee ATAM-mentelmän perusteet ja prosessin kulun arviointiin osallistujille. Perinteisessä esittelyssä käydään lyhyesti läpi ATAM-menetelmän hyödyt ja piirteet,.

(17) 9 menetelmän suorituksen vaiheet sekä analyysin lopputuotteet. Esittelyssä käydään vaiheita läpi usein esimerkkien avulla. Esittelyssä ei käydä menetelmää kuitenkaan perusteellisesti läpi, sillä riittää, että prosessin vetovastuussa oleva evaluointitiimi tuntee prosessin tarkemman kulun. Ensimmäisen työvaiheen kokonaiskesto on noin tunnin mittainen. [2] Toimenpide 2: Liiketoimintanäkökulmien esittäminen. Jotta analyysin tuloksiin voisi luottaa, tulee sekä evaluointitiimin että muiden osakkaiden ymmärtää arkkitehtuurin konteksti ja siihen vaikuttavat tärkeimmät liiketoimintanäkökulmat. Liiketoimintanäkökulmat valottavat syitä arkkitehtuurillisiin suunnitteluratkaisuihin ja niihin asetettuja rajoitteita. Tämän esityksen pitää joku projektin päättäjistä, useimmiten joko projektipäällikkö, tai asiakas jolle järjestelmä toimitetaan. Esityksessä käydään läpi mm:  järjestelmän tärkeimmät toiminnot ja konteksti  liiketoiminnalliset tavoitteet ja rajoitteet  arkkitehtuurillisesti tärkeimmät vaatimukset  liiketoiminnan kannalta tärkeät laatuominaisuusvaatimukset  tekniset rajoitteet. [1] Toimenpide 3: Arkkitehtuurin esittely. Arkkitehtuurin esittely on lyhyt, noin tunnin mittainen esitys, jonka pitää järjestelmän pääarkkitehti. Evaluointitiimille on toimitettu etukäteen kaikki arkkitehtuurin dokumentaatio ja tässä esitelmässä pyritään käymään lyhyesti läpi vain arkkitehtuurin pääkohdat. Esitelmän sisällön tärkeimmät asiat ovat arkkitehtuurin suunnitteluratkaisujen esittely, sekä järjestelmälle asetetut vaatimukset ja rajoitteet. Arkkitehtuuri tulee esitellä niillä arkkitehtuurikuvaustavoilla, jotka olivat tärkeimmät arkkitehtuuria suunnitellessa sekä niillä kuvaustavoilla, jotka selvittävät, miten tärkeimmät laatuominaisuudet on saavutettu. [1] Toimenpide 4: Arkkitehtuuriratkaisujen tunnistaminen. Arkkitehtuurin suunnittelussa käytetyt suunnitteluratkaisut on valittu sillä periaatteella, että järjestelmälle asetetut laatuvaatimukset voitaisiin täyttää. Kullakin lähestymistavalla voi olla sekä tavoiteltuja laatuominaisuuksia parantavia piirteitä että toisia, ominaisuuksia heikentäviä piirteitä. Esimerkiksi kerrosarkkitehtuuri parantaa siirreltävyyttä, mutta se voi joissain tapauksissa heikentää ylläpidettävyyttä. Tässä vaiheessa on tarkoitus koota lista käytetyistä arkkitehtonisista lähestymistavoista ATAM-prosessin myöhempien vaiheiden käyttöä varten. [1] Toimenpide 5: Laatupuun ja skenaarioiden laatiminen. Laatupuun laadinta on selkeä tapa koostaa vaatimukset ja skenaariot yhteen selkeästi luettavaan rakenteeseen. Laatupuun lehdille ideoidaan skenaarioita, eikä esitettyjen ideoiden tarvitse olla täysin loppuun asti ajateltuja. Laaditut skenaarioideat jalostetaan sellaiseen muotoon, että niitä voi käyttää myöhemmissä työvaiheissa ja asetetaan puun lehdiksi. Skenaarioiden tulee.

(18) 10 olla riittävän tarkkoja, jotta niiden perusteella voidaan testata arkkitehtuuria. Skenaarioita ideoidessa voi tulla julki täysin uusia, kirjaamattomia laatuvaatimuksia, jotka tulee lisätä laatupuun rakenteeseen. Toisaalta on mahdollista, että aikaisemmin tärkeäksi määriteltyyn laatuominaisuuteen ei ole saatu ideoitua skenaarioita lehdiksi ja se voidaan todeta vähemmän tärkeäksi laatuominaisuudeksi. Laatupuu esiteltiin tarkemmin aliluvussa 2.2.2. [1] Kun skenaariot on laadittu ja asetettu puun lehdiksi, ne priorisoidaan asteikolla: high (H), medium (M), low (L). Arvio annetaan kahdesta asiasta: kuinka tärkeä skenaario on ja kuinka vaikea ominaisuus tai kokonaisuus on toteuttaa. Vaihtoehtoisiakin priorisointitapoja, kuten numeroita voi käyttää, mutta oleellisinta on saada karkea prioriteettijako skenaarioiden välille. Skenaarioita on laadittu todennäköisesti huomattavasti enemmän kuin evaluoinnissa on aikaa käsitellä, joten priorisoinnilla saadaan valittua tärkeimmät skenaariot. Ensisijaisesti valitaan (H,H) skenaariot, joiden jälkeen käsitellään (H,M) ja (M,H) skenaariot. Muihin skenaarioihin mennään vain jos aika riittää. [1][2] Toimenpide 6: Arkkitehtuuriratkaisujen analysointi. Suunnitteluratkaisujen analysointi on työvaihe, jossa vaaditaan syvällistä arkkitehtuurituntemusta. Analysointivaiheessa toimenpide 5:n tärkeimmät skenaariot puretaan osiin ja analysoidaan. Skenaariot kuvataan, niihin merkitään arkkitehtuuriratkaisut, jotka vaikuttavat skenaarioon ja kukin suunnitteluratkaisu käydään yksitellen läpi. Kustakin skenaariosta löydetyt herkkyyskohdat, tasapainokohdat ja riskit kirjataan ylös siten, että analyysin lopuksi on saatavilla tarkka lista löydöksistä ja niiden perusteluista. Toimenpide 6 päättää ATAM-analyysin ensimmäisen vaiheen. Tarkempi kuvaus skenaarioista ja niiden analysoinnista on esitelty aliluvussa 2.2.2. Toimenpide 7: Skenaarioaivoriihi. Toimenpide 7 on hyvin samanlainen kuin toimenpide 5 sillä erotuksella, että tärkeimmät ideoinnin osallistujat ovat tässä vaiheessa evaluointiin liittyneet muut sidosryhmät. Tämän aivoriihen tarkoitus on tuoda loppukäyttäjän, asiakkaan ja muiden toimijoiden näkökulmat mukaan. Näin arkkitehtuuri saadaan testattua niitä skenaarioita vasten jotka todennäköisimmin toteutuvat. Skenaarioista valitaan työvaihe 5:n tavoin tärkeimmät, mutta valintatapa on erilainen. Kukin osakas saa tietyn määrän ”pisteitä” jaettavaksi skenaarioiden kesken ja kukin jakaa pisteensä sen mukaan, mitkä skenaariot hän haluaa käsiteltävän. Kun kaikki osakkaat ovat jakaneet pisteensä, skenaariot saadaan tärkeysjärjestykseen ja näistä valitaan tärkeimmät. Evaluointitiimi päättää, mihin kohtaan priorisoitua listaa vedetään analyysiin valittavien skenaarioiden raja. [1] Skenaarioiden ideoinnissa osakkaita kehotetaan yleensä laatimaan mm. käyttötapausskenaarioita, kasvuskenaarioita ja tutkivia skenaarioita. Käyttötapausskenaariossa kartoitetaan sitä, miten osakkaat olettavat järjestelmää käytettävän. Kasvuskenaarioissa ideoidaan tapoja miten järjestelmää oletetaan kasvatettavan ja muunnettavan. Kasvuskenaariot voivat kattaa muutoksia esimerkiksi suorituskykyyn tai.

(19) 11 saatavuuteen. Tutkivat skenaariot etsivät arkkitehtuurin rajoja tavoilla, joissa esimerkiksi kasvuskenaarion vaatimukset vaaditaan kertaluokkaa suurempina. Tutkivissa skenaaroissa arkkitehtuurista löydetään yleensä lisää herkkyys ja tasapainokohtia niistä kohdista, mistä skenaario rasittaa arkkitehtuuria eniten. [1] Toimenpide 8: Arkkitehtuuriratkaisujen uusinta-analysointi. Tämä työvaihe on lähes identtinen työvaihe 6:n kanssa. Mikäli aikaisemmissa vaiheissa on onnistuttu hyvin, tässä vaiheessa ei pitäisi tulla enää paljon tai yhtään uusia tasapainokohtia tai riskejä. Tästä syystä toimenpiteitä 7 ja 8 kutsutaan myös eräänlaisiksi testausvaiheeksi. Analysoitavia skenaarioita käsitellään 5 – 10 jäljellä olevasta ajasta riippuen. [1] Toimenpide 9: Tulosten julkistaminen. Analysointipäivän viimeisenä toimenpiteenä on esitellä kooste analyysin tuloksista. Tärkeimmät tulokset ovat:  lista arkkitehtuurin suunnitteluratkaisuista  skenaariot ja niiden priorisoinnit  laatupuu  lista riskeistä ja turvallisista ratkaisuista  lista herkkyys- ja tasapainokohdista. Edellämainitun listan lisäksi evaluointitiimi koostaa löydetyt riskiteemat, jotka on havaittavissa useista toisiinsa liittyvistä riskeistä. Lisäksi esitetään muut arkkitehtuuriin tai projektiin liittyvät yleiset huolenaiheet, jotka ovat tulleet evaluoinnin aikana esille. Näitä on esimerkiksi puutteellinen dokumentaatio tai asiakkaiden heikko luottamus toimittajan suorituskykyä kohtaan. Tulokset esitetään sekä suullisesti esitelmän muodossa että paperimuodossa, jotta tulokset olisivat arkistoitavissa. [1] 2.2.5. Analyysin jako neljään vaiheeseen. Eri lähdemateriaaleissa esitellään useita erilaista vaihejakoa, joista toisessa jaetaan neljään vaiheeseen ja toisessa kahteen tai vain yhteen vaiheeseen. Metodin kevennetyissä variaatioissa on usein jätetty osa vaiheista pois ja keskitytty analysointivaiheeseen/-vaiheisiin. Oppikirjanmukaisessa ATAM-menetelmässä on neljä vaihetta: vaiheet 0 – 3. Vaihe 0 on valmisteluvaihe, jossa evaluointitiimi saa arkkitehtuurimateriaalit tutkittavaksi etukäteen. Evaluoinnin johtajan tehtävä on päättää saatujen materiaalien perusteella, onko saatu informaatio riittävä evaluoinnin suorittamiseen. Mikäli materiaalia on liian vähän, johtaja voi tehdä päätöksen, että arkkitehtuuria ei analysoida, ellei dokumentaatiota paranneta riittävälle tasolle. Valmisteluvaiheessa ATAManalyysin tilannut asiakas perehdytetään siihen, miten evaluointi viedään läpi ja mitä tuloksia siitä saadaan irti. Vaihe 1 ja 2 ovat itse analyysivaiheet, joiden toimenpiteet on esitetty aliluvussa 2.2.4. Vaihe 1 on ensimmäinen evaluointikierros, johon kokoontuu pienempi määrä ihmisiä (3-5 henkilöä) kuin toiseen vaiheeseen. Ensimmäisen vaiheen tarkoituksena on.

(20) 12 tehdä päätös kannattaako toiseen vaiheeseen siirtyä ja tarvitaanko lisää dokumentaatiota, ja jos tarvitaan niin minkälaista. Lisäksi tässä vaiheessa kartoitetaan, mitä sidosryhmiä toiseen vaiheeseen halutaan osallistuvan. Myös vaiheen 2 evaluointitiimin kokoonpano päätetään tässä riippuen arkkitehtuurin vaatimuksista ja siitä, ketkä evaluoijat tuntevat vaatimuksiin liittyvän alan parhaiten. Esimerkiksi turvallisuuskriittisen järjestelmän evaluointiin valitaan vähintään yksi tietoturvallisuuden hyvin tunteva asiantuntija. Vaihe 2 on täyden evaluoinnin kierros, joka suoritetaan kaksi- tai kolmepäiväisenä. Toiseen vaiheeseen osallistuu evaluointitiimin ja projektin päättäjien lisäksi tärkeimmät sidosryhmät, joiden läsnäolo on nähty tarpeelliseksi. Eri sidosryhmiä on monia ja valitut sidosryhmät voisivat olla esimerkiksi ylläpitäjä, markkinoija, tuotepäällikkö, testaaja ja loppukäyttäjä. [1] Sidosryhmien merkitys korostuu aivoriihessä ja analysoinnissa (vrt. aliuku 2.2.4), eikä kaikkien osakkaiden ole tarpeellista osallistua ensimmäisen päivän toimenpiteisiin. Pienemmän mittakaavan ATAM-menetelmässä suoritetaan vain vaihe 2:n toimenpiteet, ja ensimmäisen vaiheen merkitys vähenee, mikäli evaluaatiotiimin tai sidosryhmien kokoonpanoon ei pystytä vaikuttamaan. Taulukko 2 esittelee toimenpidejaon vaiheille 1 ja 2. Taulukko 2 Vaiheiden 1 ja 2 toimenpiteet. 1 2 3 4 5 6 1 6 7 8 9. 1. Päivä ATAM esittely Liiketoimintanäkökulmien esittely Arkkitehtuurin esittely Suunnitteluratkaisujen tunnistaminen Laatupuun ja skenaarioiden laadinta Suunnitteluratkaisujen analysointi 2. Päivä ATAM esittely Skenaarioiden nopea läpikäynti Skenaarioaivoriihi Uusinta-analysointi Tulosten julkistaminen. Vaihe 1 & 2 toimenpiteet. Vaihe 2 toimenpiteet. Vaihe 3 on päätösvaihe, jossa koostetaan tulokset. Päätösvaiheessa asiakkaalle toimitetaan ATAM:n löydöksistä kirjallinen raportti, joka koostuu siitä, mitä on tehty, mitä on löydety ja mitä johtopäätöksiä on tehty. Evaluoiva taho tekee töitä myös itselleen päätösvaiheessa. Päätösvaiheessa kerätään tietoja siitä, kuinka prosessin kulku on mennyt ja kuinka sitä voi jatkossa parantaa. Lisäksi tehty analyysi arkistoidaan tapaustutkimuksena myöhempää koulutuskäyttöä varten. Arkistoituun versioon on kuitenkin tehtävä tarvittavat muutokset, jotta mahdolliset yhtiösalaisuudet ei käy ilmi [1]. ATAM jakautuu edellä mainittuihin neljään selkeään vaiheeseen, jotka suoritetaan järjestyksessä, mutta vaiheet ovat huomattavan eri mittaisia. Vaihe 0, valmisteluvaihe,.

(21) 13 voi kestää useita viikkoja ja siihen lasketaan myös se valmistelutyö, mitä on tehty ilman työstä allekirjoitettuja sopimuksia. Vaiheet 1 ja 2 ovat lyhyitä, kokonaisuudessaan kolmesta neljään päivään, mutta välissä voi olla parin viikon tauko. Tauon aikana koostetaan ensimmäisen evaluoinnin tuloksia ja valmistaudutaan toista evaluointia varten, jotta siitä saataisiin mahdollisimman paljon irti. Viimein evaluoinnin päätyttyä alkaa päätösvaihe, joka kestää noin viikon. Tänä aikana on tarkoitus tuottaa tulokset ja päättää ATAM-menetelmän mukainen analyysi.. 2.3. ATAM-menetelmän tulokset ja sivutuotteet. Edellisissä luvuissa on tullut ilmi yksittäisiä lopputuotteita ja sivutuotteita, joita ATAMevaluointi tuottaa. Prosessin ensimmäisenä sivutuotteena varmistetaan, että arkkitehtuurista on tehty riittävän laadukas dokumentaatio. Puutteellinen dokumentaatio on jo projektinhallinnallisesti riskitekijä, mihin puututaan ATAM-menetelmässä jo heti alkuvaiheessa. Prosessi pakottaa arkkitehdin tuottamaan arkkitehtuurista sekä ymmärrettävän esityksen että laadukkaan dokumentaation, jossa järjestelmä ja siinä käytetyt suunnitteluratkaisut tulevat selkeästi ilmi. Mikäli arkkitehtuurista on tehty liian vähän dokumentaatiota, tai dokumentaation tarkkuus ei ole riittävä, dokumentaatio ei ole tarpeeksi hyvä ATAM-analyysiä varten. Mikäli dokumentaatio nähdään heikoksi, ATAM-menetelmän alkuvaiheessa evaluoijien antama palaute ohjaa arkkitehtiä korjaamaan dokumentaation puutteet. Prosessin keskivaiheilla työstetään laatupuu, priorisoidut skenaariot ja suunnitteluratkaisut. Järjestelmältä vaadittavat tärkeimmät laadulliset ominaisuudet on listattu laatupuuhun heti ensimmäiselle alitasolle. Kukin laatuominaisuus on jäsennelty tarkennuksineen, jotka jakautuvat edelleen omiin skenaarioihinsa. Laatupuu itsessään antaa kokonaiskuvan siitä, mitä laatuominaisuuksia järjestelmältä odotetaan ja mihin vaatimuksiin sen pitää vastata. Laatupuun lehtinä olevista skenaarioista saadaan priorisoitu lista, josta käy ilmi mitkä skenaariot ovat tärkeimmät ja hankalimmat toteuttaa, ja mitkä skenaariot jäävät priorisoinnissa vähemmän tärkeiksi. Tulosten tärkeimmästä päästä ATAM antaa skenaarioiden analysoinnissa listan herkkyyskohdista, tasapainokohdista, riskeistä ja riskiteemoista. Siinä, missä riskit kertovat järjestelmästä löytyneet yksittäiset riskit, riskiteemat niputtavat useammat riskit yhteen. Riskiteemoissa voi käydä ilmi esimerkiksi että järjestelmässä nojaudutaan liikaa kaupallisiin tuotteisiin. Toisaalta riskiteemoissa voidaan huomauttaa, että missään dokumentissa ei käydä läpi yleiskuvaa ja siten tarkkakin dokumentaatio on vaikeasti ymmärrettävä [1]. Skenaarioissa käsitellyt arkkitehtuurin suunnitteluratkaisut sekä muut skenaarion analyysin tulokset listataan omaan dokumenttiinsa. Muihin tärkeisiin ulostuloihin lukeutuvat selkeytyneet liiketoimintanäkökulmat, jotka osaltaan vaikuttavat laatupuuhun ja skenaarioihin. On mahdollista, että osa kehittäjistä kuulee liiketoimintanäkökulmista ensimmäistä kertaa vasta ATAM-menetelmän aikana [1]. Liiketoimintanäkökulmat antavat perustelun osalle järjestelmälle annetuista vaatimuksista, mutta toisaalta niiden myötä on pääteltävissä toistaiseksi kirjaamattomia.

(22) 14 vaatimuksia. Liiketoimintanäkökulmat eivät välttämättä tule kirjalliseen muotoon koostettuna dokumenttina, mutta ne ovat silti hyvin tärkeä prosessin sivutuote.. 2.4. Analysoinnin edut ja kustannukset. Mikäli analyysin järjestää arkkitehtuurista vastaava organisaatio, analysoinnin kustannukset ovat mitattavissa lähinnä osallistujien käyttämässä ajassa. Analyysi, johon osallistuu myös asiakas, ei välttämättä tule maksamaan pelkästään arkkitehtuurista vastaavalle organisaatiolle, sillä asiakkaat voivat olla halukkaita osallistumaan omaan laskuunsa [1]. Käytetty aika riippuu paljolti osallistujien määrästä, mutta analyysin aloittamista ja suorittamista saattaa hidastaa myös organisaation heikko arkkitehtuurillinen maturiteetti [6]. Suora rahallinen hyöty on mitattavissa arkkitehtuuriin käytettävistä resursseista suhteessa arvioituihin kustannuksiin, jos projekti olisi tehty ilman analyysin pohjalta tehtyjä muutoksia. Vuonna 1997 AT&T raportoi kahdeksan vuoden ajalla tehtyjen arkkitehtuurien evaluointien pohjalta, että arkkitehtuurianalyysi on pienentänyt projektin kustannuksia keskimäärin kymmenen prosenttia. Täyden mittakaavan ATAMevaluoinnin viedessä 70 miestyöpäivää, evaluointi alkaa vähentämään projektin kustannuksia projektin pituuden ylittäessä 700 miestyöpäivää. Toisaalta on myös olemassa esimerkkejä pahasti epäonnistuneista projekteista, joissa ei ole suoritettu minkäänlaista evaluointia ja joihin on palanut mittaamattomasti rahaa [6]. Mikäli näissä tapauksissa analyysi olisi tehty varhaisessa vaiheessa, olisi ollut mahdollista joko korjata arkkitehtuuria tai hylätä projekti, mikäli vaatimuksien täyttäminen olisi nähty mahdottomaksi. Arkkitehtuurin evaluoinnissa on useita eri tekijöitä jotka hyödyttävät sekä projektia että organisaatiota. Ensimmäisenä näkyvät hyödyt ovat dokumentaation paraneminen sekä järjestelmän parempi ymmärtäminen. Arkkitehtuurin ongelmakohtien löytymisen aikana myös vaatimukset selkeytyvät ja priorisoituvat [6]. On mahdollista, että vaatimuksissa on selvästi havaittavia ristiriitoja, jotka saattavat aiheuttaa projektin myöhäisemmässä vaiheessa ongelmia. Ristiriitaisten vaatimusten priorisointi ja muuttaminen on suunnitteluvaiheessa huomattavasti edullisempaa kuin implementointivaiheessa [2]. Lisäksi perusteellisesti tehdyllä evaluoinnilla on mahdollista valaa kaikkiin osakkaisiin uskoa arkkitehtuurin suhteen ja asiakkaan uskoa toimittajaa kohtaan [6]. Tämän uskon valamisen tärkeys kasvaa etenkin silloin, kun kyseisen asiakkaan usko on vähentynyt toimittajan kykyyn toimittaa järjestelmä ennalta määritetyssä aikataulussa ja budjetissa. Organisaatiot, joissa arkkitehtuureja analysoidaan osana kehitysprosessia, ovat havainneet selkeää parannusta arkkitehtuuriensa yleisessä laadussa. Tämä johtuu siitä, että arkkitehti osaa arkkitehtuuria suunnitellessa ottaa tulevan evaluoinnin huomioon ja panostaa sitä varten. Arkkitehti osaa odottaa, minkälaisia kysymyksiä evaluoinnissa esitetään ja mitä materiaaleja siellä vaaditaan. Pidemmän ajan kuluessa on havaittavissa,.

(23) 15 että organisaation kyky suunnitella parempia arkkitehtuureja kehittyy ja organisaatio on kehittänyt yleisiä toimintatapoja tuottaa parempia arkkitehtuureja. [2][6]. 2.5. Muut evaluointimenetelmät. ATAM ei ole ainoa metodi, jolla voi analysoida ohjelmistoarkkitehtuureja. ATAMmenetelmä on SEI:n kehittämä tekniikka, joka on kehitetty heidän SAAM-menetelmän (Software architecture analysis method) pohjalta. SAAM-pohjainen analyysi on ATAM:ia suppeampi ja keskittyy lähinnä muunneltavuuden ja toiminnallisuuden analysointiin [4]. SEI on kehittänyt ATAM-menetelmän tueksi QAW-menetelmän (Quality Attribute Workshop), joka keskittyy laatuominaisuuksien kartoittamiseen ja pitkälle jalostettujen skenaarioiden tekemiseen. QAW-menetelmän skenaariot ovat suoraan käytettävissä ATAM-analyysin materiaaleina. [7] ATAM:n selvittäessä minkälaisia riskejä arkkitehtuurissa on ja mitä laatuominaisuuksia se täyttää, se ei kuitenkaan puutu kustannusseikkoihin. CBAM (Cost Benefit Analysis Method, myös SEI:n kehittämä tekniikka) pureutuu juuri näihin seikkoihin. CBAM-menetelmässä analysoidaan arkkitehtuuriratkaisujen kustannuksia, hyötyjä, epävarmuustekijöitä ja implementoinnin ajanhallinnallisia seikkoja [8]. CBAM-menetelmää voi käyttää luonnollisena jatkeena ATAM-menetelmän jälkeen, tai sen voi jopa integroida ATAM-menetelmän kanssa. [9] ATAM, SAAM ja CBAM ovat kukin vain esimerkkejä useista eri skenaariopohjaisista menetelmistä. Skenaariopohjaisuuden lisäksi on olemassa muita tapoja evaluoida ja nämä muut ovat karkeasti jaettuna kyselykaavakepohjaisia, tarkistuslistapohjaisia, metriikkapohjaisia tai protyyppipohjaisia metodeja. Nämä menetelmät on karkeasti jaettavissa kahteen kategoriaan: kyselypohjaiset tekniikat ja mittauspohjaiset tekniikat. Mittauspohjaiset tekniikat ovat suppeita ja vastaavat lähinnä suorituskyky- ja muunneltavuuskysymyksiin. Kyselypohjaisista tekniikoista kyselykaavake- ja tarkistuslistametodit ovat nopeita tapoja evaluoida, mutta analyysi ei ole välttämättä syväluotaavaa ja listojen kysymykset voivat olla sisällöltään helposti liian yleisluontoisia. Kyselypohjaisista tekniikoista viimeinen, skenaariopohjainen tekniikka puolestaan mahdollistaa tarkemman analyysin, mutta se näkyy suoraan evaluoinnin kustannuksissa. [6] Evaluointitapoja on siis monia erilaisia. ATAM-menetelmän ollessa vain yksi monista se erottuu edukseen siinä, kuinka kattavasti sillä voi arkkitehtuurin analysoida. Mikäli käytetyltä menetelmältä halutaan vastauksia kysymyksiin mihin ATAM ei vastaa, tai halutaan edullisempi ja nopeammin suoritettava metodi, on olemassa useita muitakin metodeja, joista jokin voi vastata paremmin tarpeisiin. Evaluointi on kuitenkin prosessi, minkä tehokas suorittaminen vaatii kokemusta ja siten on viisasta harkita mitä menetelmää käyttää..

(24) 16. 2.6. Yhteenveto. ATAM on prosessina hyvin selkeä ja työvaiheet on määritelty tarkkaan ja jopa aikataulustakin voi tehdä minuuttiaikataulun. Pelkkä kirjatietous ei kuitenkaan riitä menetelmän hyvään suorittamiseen, vaan prosessin menestyksekäs läpiajo vaatii evaluointitiimiltä vankkaa arkkitehtuurillista kokemusta. Laatuominaisuuksien, suunnitteluratkaisujen ja riskien tunnistaminen ovat menetelmän onnistumisen kannalta oleellista, ja kokemattomalla tiimillä jotain oleellista saattaa jäädä huomaamatta. Menetelmän toistuva suorittaminen on kuitenkin oiva tapa kartuttaa kokemattoman tiimin tai yksittäisten tiimiläisten kokemusta, jotta tulevat evaluoinnit olisivat hedelmällisempiä. Vaikka täysimittaisen ATAM-menetelmän käyttö voikin olla kallista, sen suorittaminen ei vie kovin paljon kalenteriaikaa. Menetelmän tuomat säästöt ovat tuntuvia vain, jos projektin mittakaava on tarpeeksi suuri. Mikäli osallistujien määrää vähennetään ja suoritettuja vaiheita kevennetään, ATAM on sovellettavissa myös pienemmässä mittakaavassa, jolloin siitä tulee käyttökelpoinen työkalu myös pienempiin projekteihin. Kevennetyssä menetelmässä on kuitenkin mahdollisuus, että osa arkkitehtuurin riskeistä jää huomaamatta. Vaikka kaikkia riskejä ei saataisikaan kiinni, menetelmä maksaa nopeasti itsensä takaisin, jos arkkitehtuurista on löydettävissä vakavia riskejä..

(25) 17. 3. ANALYSOITAVA OHJELMISTO. Tässä luvussa esitellään arkkitehtuuri, johon ATAM-menetelmää on sovellettu. Ohjelmisto ja sen käyttökohteet on kuvattu suppeasti, osittain, koska ohjelmiston koko on melko mittava, ja osittain, jotta ohjelmiston tarkempi käyttökohde pysyisi salassa. Arkkitehtuurin kuvaus on esitetty sillä tarkkuudella, että myöhemmin luvussa 4 esitetty menetelmän suoritus ja skenaariot olisivat helposti ymmärrettävissä. Ohjelmisto on jo valmis, joten tämän diplomityön puitteissa tehty analyysi on tehty valmiista tuotteesta. Analysoitavaan ohjelmistoon viitataan seuraavissa luvuissa vain nimellä ohjelmisto, tai monitorointiohjelma. Tämä luku jakautuu rakenteellisesti useampaan eri osaan. Ensin aliluvussa 3.1 esitellään ohjelmiston tehtävät tekniseltä näkökulmalta. Todellisella käyttöympäristöllä ja lopullisilla käyttötapauksilla ei ole ohjelmiston toiminnan ymmärtämisen kannalta kovin paljon merkitystä. Ohjelmiston esittelyn jälkeen esitellään aliluvussa 3.2 vaatimukset ja ominaisuudet, joita ohjelmistolta odotetaan. Aliluku 3.3 kattaa teknisen kuvauksen koko arkkitehtuurista ja on siten aliluvun 4.4 skenaarioiden ymmärtämisen kannalta erittäin tärkeä. Lopuksi aliluvussa 3.4 käydään läpi tärkeimmän laatuominaisuuden, varioinnin, vaikutusta arkkitehtuuriin ja aliluvussa 3.5 niitä haasteita, joita tehdyt arkkitehtuurilliset lähestymistavat aiheuttavat.. 3.1. Analysoitava ohjelmisto ja sen tehtävät. Analysoitava ohjelmisto on monitorointi- ja tallennusohjelmisto, minkä päätehtävä on lukea CAN-väylältä (engl. Controller Area Network bus) dataa, esittää sitä reaaliaikaisesti käyttäjälle ja tallentaa tietokantaan myöhempää tarkastelua varten. Ohjelmisto on kehitetty käyttäen Qt 4.x kehystä ja kohdealustana toimii sulautettu Linux-käyttöjärjestelmä. Käyttöjärjestelmä on peitetty käyttäjältä siten, että tietokoneen käynnistyttyä monitorointiohjelma on ainoa käyttäjälle näkyvä ohjelma, eikä käyttäjällä ole pääsyä konsoli- tai työpöytäohjelmiin. Tietokoneen käynnistyttyä monitorointiohjelmisto aloittaa datankeruun automaattisesti. Vastaanotettu data jäsennetään yleiskäyttöiseen muotoon ja datan pohjalta suoritetaan laskentaa, minkä jälkeen data on käyttäjän ja tietokannan kannalta hyödyllisessä muodossa. Näiden lisäksi samaa jalostettua dataa voidaan välittää lähiverkkoon liitettyihin kolmannen osapuolen ohjelmistoihin niin kutsutun reaaliaikadatan rajapinnan (myöhemmin RT API, engl. Real-Time Application Programming Interface) kautta. Tämä kaikki tapahtuu riippumatta siitä, mitä käyttäjä tekee käyttöliittymällä, sillä tietokoneen käynnistyttyä käyttäjällä on oikeudet vain tarkastella dataa. Kuva 5 esittää järjestelmän yksinkertaistetun rakenteen..

(26) 18 Tietokone Näyttö. Sulautettu Linux HW moduulit. Dataa. Kolmannen osapuolen ohjelmistot. Analysoitava ohjelmisto. Tietokanta. Kuva 5 Yksinkertaistettu tietovuokaavio järjestelmästä. Data etenee järjestelmässä pääosin yksisuuntaisesti oheislaitteilta monitorointiohjelmistolle ja siitä eteenpäin. Tietokoneessa on integroitu laitteistotuki mm. CAN-väylille ja sarjaporteille. Lopullinen väyläkonfiguraatio voi vaihdella eri varianttien välillä. Monitorointiohjelmisto lähettää hyvin vähän dataa väylille ja sekin data on pääsääntöisesti tietojen pyytämistä. CAN-väylään kytketyt oheislaitteet lähettävät automaattisesti jatkuvasti dataa ilman, että sitä pitää erikseen pyytää, ja erillistä pyyntöä vaativien viestien määrä on murto-osa koko väyläliikenteestä. Monitorointiohjelmiston pääasiallinen tiedonlähde on CAN-väylä, joten seuraavissa arkkitehtuurikuvauksissa keskitytään eniten siihen, miten CAN-data etenee arkkitehtuurin läpi.. 3.2 Arkkitehtuurisuunnittelua ohjaavat vaatimukset ja ominaisuudet Monitorointiohjelmiston vaatimukset on asiakkaan puolesta erittäin tarkkaan määritelty käyttöliittymän kosmeettisia yksityiskohtia myöten. Suuri osa vaatimuksista määräytyi loppukäyttäjän vaatimien toiminnallisuuksien pohjalta, jotka muodostivat ohjelmiston ensisijaiset vaatimukset. Näiden lisäksi arkkitehtuurisuunnitelmissa oli otettava huomioon asiakkaan liiketoimintanäkökulmat, joista moni tähtäsivät tulevaisuuden tuotekehityskustannuksien minimoimiseen. Ensimmäisessä aliluvussa on käsitelty arkkitehtuurille asetettuja yleisiä vaatimuksia, sekä laatuominaisuuksia (aliluku 3.2.1) ja myöhemmin toisessa aliluvussa liiketoimintanäkökulmia (aliluku 3.2.2). Vaatimuksia tulee tämän aliluvun lisäksi ilmi myöhemmin arkkitehtuurin kuvauksessa (aliluku 3.3). 3.2.1. Yleiset vaatimukset ja laatuominaisuudet. Tärkein arkkitehtuurille asetettu laatuvaatimus on varioitavuus. Ohjelmistosta on räätälöity useita eri tuotteita, joissa on vain osittain yhtenevät toiminnallisuudet. Tästä johtuen toiminnallisuuksia pitää olla helppo lisätä ja poistaa tuotteesta. Osa ominaisuuksista saattaa olla kahden eri tuotteen välillä pääosin samanlaiset, mutta toiminnassa voi olla eroavaisuuksia. Tästä johtuen suurin osa moduulien toiminnallisuuksista pitää olla alusta lähtien konfiguroitavissa, jotta moduuli olisi.

(27) 19 käytettävissä uudelleen useaan eri tuotteeseen. Varioitavuus on johtanut siihen, että arkkitehtuuri koostuu kolmenlaisista elementeistä: kaikille tuotekonfiguraatioille yhteisestä ydinkoodista, yksittäisiä ominaisuuksia toteuttavista moduuleista ja moduulien konfiguraatiotiedostoista. Ohjelmistolle ei ole asetettu kovia reaaliaikavaatimuksia, mutta suorituskyvyn tulee olla hyvä. Arkkitehtuurin odotettu elinkaari on hyvin pitkä ja on odotettavissa, että kyseisen arkkitehtuurin pohjalta tehdään useita eri tuotekonfiguraatioita. Koska tulevien tuotekonfiguraatioiden vaatimuksia ei vielä tunneta, tulee varmistua, että arkkitehtuuri selviää kuormituksen kasvaessa. Osaltaan haasteita tuo se, että tietokantaan ja RTrajapintaan halutaan päivitykset kaikista sisään tulevista viesteistä, mikä aiheuttaa kuormaa kaikille kerroksille. Päivitystahdille on kuitenkin määritelty yläraja, jolloin ohjelman ylikuormitus ei ole niin suuri riski. On mahdollista, että tulevissa tuotekonfiguraatioissa on kytkettynä enemmän dataa tuottavia oheislaitteita, tai tuotteeseen tarvitaan uusia raskaita ominaisuuksia, joten arkkitehtuurin tulee olla alusta lähtien mahdollisimman kevyt. Ohjelmiston asennukseen liittyvä vaatimus on, että ohjelmisto tulee olla asennettavissa kohdetietokoneeseen siirrettävästä mediasta, kuten USB-muistitikulta (engl. Universal Serial Bus) ja asennustoimenpiteiden määrän tulee olla minimoitu. Asennuksen yhteydessä kohdetietokoneeseen tulee asentua karsittu Linuxkäyttöjärjestelmä ja mahdollinen edeltävä asennus poistetaan. Mikäli tietokoneella on jo valmiina edeltävä versio asennettavasta ohjelmistosta, ohjelmiston tuottamat datat tulee säilyä omalla osiollaan asennuksen yli. Asennuspaketista tulee olla tehtävissä myös päivityspaketti, jonka pystyy asentamaan edellisen ohjelmaversion käyttöliittymän kautta turvautumatta esimerkiksi Linux-käyttöjärjestelmän komentorivikonsoliin. 3.2.2. Liiketoimintanäkökulmat. Tärkein syy uuden arkkitehtuurin uudistamiseen oli tulevaisuuden tuotekehityskustannuksien pienentäminen. Tuotteen edeltävä koodihaara oli kasvanut suuremmaksi ja monimutkaisemmaksi kuin silloinen arkkitehtuuri salli ja siten silloinen arkkitehtuuri oli tullut elinkaarensa päähän. Tuotteen jatkokehitys oli edeltävällä arkkitehtuurilla hidasta ja pienillä koodimuutoksilla saattoi olla arvaamattomia vaikutuksia koko ohjelmiston kannalta. Asiakkaan tulevaisuudennäkymät osoittivat, että tuotteen elinkaari tulee olemaan pitkä ja varianttien määrä tulee kasvamaan, joten arkkitehtuurin kokonaisvaltainen uusiminen paremmaksi tulisi pitkällä aikavälillä maksamaan itsensä takaisin. Jotta uuden arkkitehtuurin tuotekehityskustannukset pysyisivät matalana, seuraavat laaatuominaisuudet nousivat hyvin tärkeään asemaan: muunneltavuus, varioitavuus ja konfiguroitavuus. Tuotteen tulee olla muunneltava ja konfiguroitava, jotta tuote pystyy toimimaan täydellä kapasiteetilla eri kohderaudoissa ja käsittelemään erilaisten oheislaitteiden viestejä. Lisäksi tuotteen tulee olla siten varioitava, että uutta tuotekonfiguraatiota tehtäessä kaikki edeltäviin tuotekonfiguraatioihin tehdyt moduulit ovat käytettävissä ilman koodin kopiointia tai moduulien uudelleenkoodaamista. Nämä.