Arkkitehtuurin arviointiin päätettiin käyttää DCAR-arviointimallia. Tähän päädyttiin, sillä ATAM koettiin liian raskaaksi ja lisäksi toteutettava kokonaisuus ei sisällä kriittisiä laatu-kriteereitä joita tulisi arvioida. Kuitenkin varhaisessa vaiheessa huomattiin myös DCAR:n olevan liian raskas sellaisenaan. Pienellä kehittäjäporukalla toteutettavan sisäisen projek-tin arviointiin ei ole mielekästä käyttää arviointimallia kokonaisuudessaan. Lisäksi haluttiin arkkitehtuurin arvioinnin olevan mahdollisimman helppoa ja kevyttä, jotta kynnys ottaa se käyttöön tulevaisuudessa olisi matala.
Toiveiden mukaisesti DCAR:a kevennettiin jättämällä priorisointi ja asiakkaan esittelyt pois. Sisäisessä projektissa ei ole suuri tarve esitellä asiakasta. Lisäksi päätöksiä ei prio-risoitu, sillä niiden määrä oli ennalta määrätty. Helppoutta haettiin käyttämällä käyttäjäta-rinoita (engl. user story) voimien rinnalla tukemaan päätösten arviointia. Käyttäjätarinat kuuluvat olennaisena osana nykypäivän ketterään ohjelmistokehitykseen. Ketterässä oh-jelmistokehityksessa käyttäjätarinoiden avulla arvioidaan ja testataan kehitysjakson (engl.
sprint) tehtäviä, joten niiden käyttäminen myös arkkitehtuurin arvioinnissa oli hyvin luon-tevaa.
Arkkitehtuurin arvioinnissa päätettiin keskittyä suurimmaksi osaksi moduuleihin, sillä ne ovat kokonaan uusi kokonaisuus komponenttikirjastoja uudistaessa. Täysin uutena osa-na moduuleihin liittyy todennäköisimmin suuremmat riskit kuin muihin arkkitehtuurin osiin.
Lisäksi moduulit olivat hyvä arvioinnin kohde, sillä niistä ei ollut luonnollisesti ollenkaan dokumentaatiota olemassa. Arvioinnissa keskityttiin erityisesti moduulien perusperiaattei-siin, jotta saadaan rakennettua vankka pohja moduulien suunnittelua varten. Perusperi-aatteiden dokumentoinnilla saadaan aikaan helposti vaatimukset, jotka ohjaavat moduu-lien toteutuksen suunnittelua.
Yksi tärkeimmistä perusperiaatteista oli moduulien muodostaminen kirjastoista. Kuinka moduulit muodostetaan, vaikuttaa paljon siihen, kuinka helppo niitä on ylläpitää ja käyt-tää. Tätä kokonaisuutta tarkastettiin BD ympäristön näkökulmasta, sillä se tullaan jatkos-sa koostamaan moduuleista. Lopullisesjatkos-sa arvioinnin lopputuloksisjatkos-sa korostui ylläpidon merkitys niin käyttäjän kuin sovelluksen toimittajan näkökulmasta.
Kuva 7.1.Dokumentoitu arkkitehtuuripäätös itsenäisistä moduuleista
Ensimmäisenä vaihtoehtona oli tehdä moduuleista täysin itsenäisiä (Kuva 7.1). Lopulli-nen ympäristö koostuisi vain yhdestä moduulista, jossa on määritelty kaikki sen sisältä-mät kirjastot. Kaksi muuta päätöstä taas perustuvat siihen, että moduulit voivat sisältää muita moduuleita. Tällöin kirjastomäärittelyt jakaantuvat monen eri moduulien kesken ja yksittäisten ympäristöjen ylläpito hankaloituu. Monet kirjastot ovat kuitenkin eri ympäris-töille yhteisiä, joten niiden määrittely moneen kertaan ei ole viisasta. Lisäksi tämä han-kaloittaa kokonaisuudessa ympäristöjen ylläpitoa, mikä muodostuu itsenäisten moduu-lien isoimmaksi ongelmaksi. Itsenäiset moduulit ovat myös käyttäjän näkökulmasta liian joustamattomia. Näin ollen yksimielisesti todettiin itsenäisen moduulin olevan sopimaton ratkaisu moduulien muodostamiseen
Ylläpidon näkökulmasta on mielekästä määrittää moduuleita niin, että ne voivat sisältää muita moduuleita. Näin pystytään vähentämään redundantin datan määrää ja tuomaan joustavuutta, jota ei saavutettu itsenäisten moduulien kanssa. Seuraavat kaksi ratkaisua perustuvat juurikin siihen, että moduulit voivat sisältää muita moduuleja. Ainoana erona on se, että saavatko moduulit mukauttaa alimoduuleitaan.
Ensin otetaan käsittelyyn päätös, jossa moduuleita saa muokata (kuva 7.2). Muokkauk-sella tarkoitetaan tässä tapauksessa vain aktiivisuuden muokkaamista eli kirjastojen
pii-Kuva 7.2.Dokumentoitu arkkitehtuuripäätös muokattavista moduuleista
lottamista käyttöliittymästä. Kirjastoja ei poisteta, vaan ne jätetään toisten kirjastojen käyt-töön. Kirjastojen piilotus on tärkeä ominaisuus suunnittelijan kannalta, jotta vain oleelliset kirjastot näkyvät käyttöliittymässä. Kirjastoja ei voida kuitenkaan poistaa kokonaan, sillä vielä ei ole mekanismia selvittää kirjastojen riippuvuuksia. Ei voida siis tietää, että onko tiettyyn kirjastoon viittauksia muista kirjastoista.
Muutettavien moduulien suurin ongelma kuitenkin liittyy aktiivisuuksien säätämiseen. Ak-tiivisuuksien säätö on hyvä ominaisuus, mutta siinä ajaudutaan helposti ongelmatilantei-siin. Kaksi eri moduulia voivat helposti määrätä saman kirjaston samaan aikaa aktiivisek-si ja ei-aktiivisekaktiivisek-si. Lopputuloksena helposti syntyvät loogiset ongelmat aiheuttavat sen, että muokattavista moduuleista ei ollut lopulliseksi ratkaisuksi.
Viimeinen päätös on hyvin samanlainen kuin muokattavat moduulit. Muokkaamattomat moduulit myös voivat sisältää muita moduuleita ja niistä koostetaan lopullinen ympäris-tö (kuva 7.3). Toisin kuin aiemmassa pääympäris-töksessä nyt ei sallita edes muokata moduulin kirjastojen aktiivisuutta. Syynä tähän on aiemmin mainitut loogiset ongelmat, jotka ai-heuttivat muilta osin hyvän päätöksen hylkäyksen. Muokkaamattomat moduulit voivat olla
Kuva 7.3.Dokumentoitu arkkitehtuuripäätös muokkaamattomista moduuleista
riittämättömiä käyttäjän kannalta, mutta ongelma täytyy ratkaista muuten kuin muokkaa-malla moduuleja. Toinen mahdollinen ongelma voi olla sisäisesti tarpeet korvata tiettyjä kirjastoja moduuleissa. Silti muokkaamattomat moduulit ovat selkeästi paras vaihtoehto ja siitä kannattaa lähteä liikkeelle.
Muut arvioinnit liittyivät myös moduuleihin. Ensimmäisissä arvioinneissa haettiin perus-teita moduulien ja kirjaston käyttöön tuoteversioiden ja ylläpidon vähentämiseksi sekä etsittiin vaihtoehtoisia lähestymistapoja. Sen jälkeen arvioitiin erilaisia tapoja kirjastojen jakamiseksi moduuleihin. Tämän jälkeen arvioitiin aiemmin esiteltyjen moduulien muo-dostamisen periaatteet. Moduulien muodostamiseksi oli päätetty sallia sisäkkäiset mää-rittelyt eli moduuli voi sisältää muita moduuleja. Viimeiseksi arvioitiin sitä kuinka monta peräkkäistä moduuliviitettä kannattaa olla peräkkäin lopullisessa ympäristörakenteessa.
Kaikkiin arviointeihin osallistui yhteensä kolme henkilöä. Arviointeihin osallistuneilla hen-kilöillä oli hyvä tietämys arvioinnin kohteen taustaympäristöstä ja sovelluksen nykytilasta.
Arvioinneissa muodostui käsitys siitä, että moduulit ovat perusteltu ratkaisu ympäristöjen ylläpidon keventämiseksi ja tuoteversioiden vähentämiseksi. Arvioinneissa saatiin aikaan myös selkeät periaatteet moduuleille. Itse arvioinnit koettiin onnistuneeksi, sillä konkreet-tisten dokumenttien ja päätösten lisäksi jokaisen osallistujan ymmärrys arvioinnin koh-teista kasvoi merkittävästi.
Yksittäisenä epäonnistumisena koettiin osittain moduulien jakoon liittyvän päätöksen ar-viointi. Siinä pitkälti valmistelussa oli päätöksen ongelma rajattu huonosti. Tämä johti sii-hen, että pitkälti ongelman reunaehdot sanelivat lopputulosta. Siitä johtuen itse päätök-sestä ja ongelmasta ei löydetty merkittävästi uusia näkökulmia. Paremmalla valmistelulla voidaan vähentää riskiä joutua arviointitilanteessa umpikujaan.
Tällä kertaa ei nähty tarvetta arvioida päätöstä uusiksi uudella ongelman rajauksella. Uu-delleenrajauksen lisäksi voitaisiin tehdä myös yksittäisten päätösten uudelleenarviointi-kin, mikäli argumentit ja niiden taustalla olevat voimat ovat huomattavasti muuttuneet.