1(18) JAKELU Koko VYM-ryhmä Vers Muuttaja Pvm Muutos Tarkastanut Hyväksynyt 1.0 22.4.2001 Alkuperäinen versio Luonnos 1 1.0 23.4.2001 Muutama liäsys ja tarkennys Antti Tuomaala Laatukatselmus LU 1. Suunniteltu laaduntarkkailu Edellisessä vaiheessa tehtiin kattava laatukatselmus, josta tarkoituksella jätettiin yksi kohta luovutusvaiheeseen. Ko. laatukriteeri on esitetty seuraavassa taulukossa (joka on siis osa alkuperäistä laatusuunnitelmaa). No Pri Kriteeri Mittari Tavoite Perustelut 7 10 Onko toteutettu mitä on suunniteltu? Vertaillaan suunnitteludokumenttej a teknisiin dokumentteihin ja ohjelmistoon. Todetaan seuraavat asiat: ominaisuudet, jotka on toteutettu kuten suunniteltu ominaisuudet, jotka puuttuvat kokonaan ominaisuudet, jotka on toteutettu puutteellisesti tai väärin ominaisuudet, jotka on toteutettu, mutta ei suunniteltu On toteutettu juuri ne ominaisuudet mitä on suunniteltu. Puuttuvat ja puutteelliset ominaisuudet todetaan, pohditaan miksi näin on käynyt ja pyritään korjaamaan projektin seuraavassa vaiheessa. Kriteerin tarkastelu on aika työläs prosessi, mutta sen tulokset toivon mukaan kertovat paljon projektin laadusta. Muut luovutusvaiheen laadunvarmistukseen liittyvät prosessit (jotka ovat tämän muistion ulkopuolellla, mutta tullaan silti toteuttamaan): Järjestelmätestaus, testien hyväksyminen Dokumenttien läpikaynti, hyväksymiset.
2(18) Johtoryhmän luovutustilaisuus 2. Laatukatselmukset tulokset 2.1. Tarkasteltavat tuotokset Aivan kaikkea tuotettua ei voida analyyttisesti läpi kohtuullisessa ajassa. Tähän tarkasteluun on pyritty valitsemaan tärkeimmät tuotettuun sovellukseen liittyvät dokumentit ja itse tuote koko kehityskaaren ajalta määrittelystä tuotteeseen. Tämä kehityskaari käy selville melko hyvin seuraavia dokumentteja ja tietoja hyväksi käyttäen: Vaatimusmäärittely (huomaa prioriteetit) Toiminnallinen määritttely Tekninen määrittely Itse tuote (apuna JavaDoc dokumentointi) Lisäksi: Projektisuunnitelma Listatut dokumentit muodostavat eräänlaisen jatkumon periaattella listassa edellinen määrittelee seuraavan. Käytännössä tilanne ei tietenkään ole näin yksiselitteinen, joten ristiriitaisuuksien selvittäminen ei ole ihan yksinkertainen tehtävä. Tässä katselmuksessa pyritään kuitenkin siihen niin hyvin kuin mahdollista. Projektisuunnitelmassa on esitetty lista tärkeimmimstä tavoitteista. Onkin järkevää tarkastella lopputuotetta myös projektisuunnitelman kannalta, jotta suunitelmien ja toteutuksen puutteisiin saataisiin vähän todellista perspektiiviä, eikä takerruittaisi liikaa kritisoimaan sellaisia puutteita, jotka eivät ole asiakkaalle tärkeitä. 2.2. Katselmuksen tulokset 2.2.1. Projektin luonne Aivan aluksi asiakkaalla ja itse ryhmällä oli vaikeuksia hahmottaa projektin todellista luonnetta. Keskustelut ja visiot olivat todella mielenkiintoinsia, mutta niiden pudottaminen realisitiselle tasolle oli vaikeaa. Vaatimusmäärittelyyn saatiin projektin luonne kuitenkin määriteltyä järkeväksi, mutta jälkikäteen on helppo todeta, miten alkuperäisissä painotuksissa ei ole voitu pysyä. Vaatimusmäärittely: Virtuaaliyhteisöjen muodostamista käsittelevä projekti on tutkimushanke. Tämä vaikuttaa suunnitteluvaiheisiin ja luonnollisesti toteutuksen painopisteisiin. Tutkimuksen tarkoituksena on tutkia ja kehittää algoritmeja ja menetelmiä, joiden avulla voidaan muodostaa virtuaaliyhteisöjä, samankaltaisten käyttäjien muodostamia
3(18) yhteisöjä. Suurimmat haasteet löytyvät siis suunnittelun ja algoritmien kehittämisen alueelta. Toiminnallinen määrittely kuvaa samaa asiaa enemmän tehtävän sovelluksen näkökulmasta. Toiminnallinen määrittely: VYM on erillinen muuhun palveluun liitettävä sovellus joka muodostaa virtuaaliyhteisöjä käyttäjistä ja palveluista annettujen sääntöjen mukaan. Tärkeimmät toiminnot ovat virtuaaliyhteisöjen muodostaminen, käyttäjien, palveluiden ja yhteisöjen lisääminen ja muokkaaminen, sekä käyttäjän virtuaaliyhteisöjen tietojen välittäminen asiakassovellukselle. Vaatismäärittelyn kuvaamassa tavoitteessa ei ole voitu pysyä. Melko pian kävi selväksi, että kurssin luonne ei sovi kovin yhteen määrittelämme projektin luonteen kanssa. Kurssin vaatimukset sopivat konkreettisen tuotteen kehitykseen, jossa tavoitteena on ohjelma, jossa on selkeä käyttöliittymä. Käytännössä projektin luonne muuttui huomattavasti. Alkuperäisen suunnitelman mukaan demoliittymät olisivat nopeasti tehtyjä esimerkkejä siitä, miten VYM-järjestelmää voitaisiin käyttää. Oikeasti demoliittymiin käytettiin runsaasti aikaa ja itse tutkimus jäi kaiken tämän kiireen alla pahasti jalkoihin. 2.2.2. Tehtävä tuote Itse tuote saatiin määriteltyä aiheen vaikeudesta huolimatta kohtuuhyvin jo alkuvaiheessa. Vaatimusmäärittely kuvailee järjestelmää lyhyesti, mutta osuvasti. Vaatimusmäärittely: Asiakkaan tarpeena on saada järjestelmä, joka kykenee ensisijaisesti asiakasprofiileja luokittelemalla luomaan virtuaaliyhteisöjä. Järjestelmän tulee tarjota puitteet, joiden avulla ryhmän jäsenet voivat kommunikoida keskenään, sekä tutkia, mihin ryhmiin he kuuluvat. Tekninen määrittely on hajoittanut vaatimukseen teknisiin osiin, joiden avulla vaatimus eli tuote voidaan kenties toteuttaa. Tekninen määrittely (ensimmäinen versio, uutta määrittelyä korjattu): AMOK hoitaa Admin-sovelluksen ja portaalin yhteydet varsinaiseen VYM:in ja tietokantaan. VYM-kone sisältää kaiken älykkyyden mitä tarvitaan virtuaaliyhteisöjen muodostamiseen. Tietokanta sisältää käyttäjäprofiilit, palveluprofiilit ja yhteisöprofiilit, sekä näiden väliset suhteet.
4(18) Admin-sovelluksessa on käyttöliittymä jolla voidaan lisätä ja päivittää käyttäjä-, palvelu- ja yhteisöprofiileja. UserPortal on loppukäyttäjän käyttöliittymä järjestelmään. Loppukäyttäjän palveluja on luonnollisesti rajattu siten, että käyttäjä voi muuttaa vain omia tietojaan. Lopullinen tuote: AMOK tarjoaa kaikki palvelut VYM järjestelmän asiakkaille. AMOK ei kuitenkaan ohjaa kantaa, vaan tämä on jätetty VYM:n ohjauslogiikan huoleksi. Alkuperäisestä ideasta ei ole kuitenkaan menty juurikaan metsään. Teknistä rakennetta on tarkennettu niin, että VYM-rajapinnan alla oleva logiikka ohjaa kantaa ja konetta. Näin koneen ei tarvitse tietää mitään kannasta. VYMlogiikalle on tehty mahdollisimman yksinkertainen rajapinta, jossa käyttäjiin, palveluihin tai yhteisöihin viitataan vain niiden ID numeroilla. Logiikkaosan kirjoittaminen on näin mahdollisimman yksinkertaista ja se on myös vaihdettavissa todella helposti. Esimerkiksi tuotteen alkuvaiheessa teimme vain yksinkertaisen StubVym koneen, joka vain palautti kovakoodattuja yhteisöjä jne. Näin esim. portaalin kehitys oli mahdollista ilman toimivaa yhteyttä kantaan. AMOK nimisen moduulin tehtäväksi jäi pelkästään palvelujen tarjoaminen ja paketoiminen niin, että koko järjestelmän käyttö olisi mahdollisimman helppoa. Esimerkiksi portaali näkee käyttäjän oliona jolta voi kysyä sen perustietoja (nimi) ja tiedustella mihinkä yhteisöihin tällä hetkellä kuulutaan. VYM-kone todella sisältää kaiken sen älyn jota tarvitaan. Koneen toteutuksesta saatiin suunniteltua melko yksinkertainen, joten itse älyn vaihtaminen ei pitäisi olla vaikeaa. Uusien koneiden toteutus on helppoa. Admin eli järjestelmän hallintatyökalun toteutus sisältää juuri teknisen määrittelyn ominaisuudet Myös portaali toteutettiin määritelmän mukaan. Projektisuunnitelmassa asiakkaan ensimmäinen ja tärkein tavoite oli: Virtuaaliyhteisöjen muodostaminen käyttöprofiileista ja tästä saatava tietämys, jota voidaan hyödyntää yrityksessä Tämä tavoite saatiin toteutettua yksinkertaisella koneella yksinkertaisesta käyttöprofiileista. Toki toivomme yrityksen hyötyvän tästä tutkimuksen ja tuotteen kokonaisuudesta tulevaisuudessa. Kolmanneksi tärkein esitetty tavoite oli: Sääntöjen luominen ja niiden kehittäminen ( kuuluvat oleellisena osana virtuaaliyhteisöjen muodostamiseen)
5(18) Sääntöjä eli tässä tapauksessa VYM-koneita toteutettiin vain se yksi, mutta tutkimusraportissa esitetään joitakin kehittyneempiä ja kenties paremmin toimivia sääntökoneita. Tämän tavoitteen tutkimiseen ryhmä olisi voinut käytttää vaikka koko kurssin, mutta tämäkää ei olisi taannut mitään erityisiä tuloksia. Vastaavia ongelmia tutkitaan yliopistotasolla laajahkostikin, mutta tyhjentäviä ratkaisuja ei liene vielä kehittänyt kukaan. Vaikka tuotteen määrittely ja toteutus onkin yleisesti onnistunut, niin portaali ja hallintatyökalu veivät liikaa aikaa. Nyt VYM-koneita saatiin toteutettua vain yksi vaikka alun perin tavoitteet olivat korkeammalla. Tärkeä pointti on kuitenkin se, että asiakkaan kaksi korkealle arvostavaa tavoitetta pysyttiin kohtuudella toteuttamaan. 2.2.3. VYM järjestelmän toiminta Miten järjestelmä lopulta toimii, on osittain päällekkäienen asia edellisen kappaleen kanssa, mutta koetetaan irrottaa tärkeästä aiheesta lisää irti. Vaatimumäärittely kuvaa toimintaa abstaktilla tasolla, mutta melko laajasti. Vaatimusmäärittely: Ohjelmiston tulee kyetä muodostamaan virtuaaliyhteisöjä. Määritelmän mukaan yhteisön jäsenillä tulee olla samankaltainen käyttäjäprofiili. Lisäksi heidän tulee voida kommunikoida keskenään (kommunikointi, prioriteetti 2). Käyttäjien tulee myös olla tietoisia siitä, mihin yhteisöihin he kuuluvat.... Virtuaaliyhteisöjä muodostavan ohjelmiston toiminnot voidaan jakaa ylläpidon ja käyttäjien suorittamiin toimintoihin. Ylläpidon toimintoihin on liitetty myös käyttäjäprofiilien analysoiminen. Tämän tehtävän voi ylläpito käynnistää, mutta periaatteessa ohjelmisto voi tarpeen vaatiessa tai ajastettuna suorittaa toiminnon myös oma-aloitteisesti Tärkein toiminto on käyttäjäanalyysin suorittaminen ja käyttäjäprofiilien liittäminen virtuaaliyhteisöihin profilien parametrien ja virtuaaliyhteisöjen sääntöjen perusteella. Käyttäjälle ja ylläpidolle tämä toiminto on periaatteessa läpinäkyvä, vaikka ylläpito voi toiminnon halutessaan käynnistää. Toiminnallinen määrittely kuvaa järjestelmän toiminnan yksityiskohtaisemmin siten, että kaikki rajapintojen toiminnat on kuvattu. Tekninen määrittely kuvaa moduulit ja moduulien rakenteet, joilla tavoitteeseen päästään. Ohessa lainaus moduulien yleisestä kuvauksesta. Tekninen määrittely: VymMachine: Yhteisöjen muodostamisen äly
6(18) Vym: Älykkään järjestelmän rajapinta ulospäin. Yhteisöjen muodostamisen logiikka. Koneen ja kannan ohjaus VymDb: Tietokanta rajapintoineen. Amok: Muodostaa Vym:n yksinkertaisesta rajapinnasta käyttäjä-, palvelu- ja yhteisöluokat, jotka itse tietävät tilansa. Esim. käyttäjältä voidaan kysyä suoraan ne yhteisöt, joihin se kuuluu. AmokWrapper: Kokoelma luokkia, jotka laajentavat Amok moduulia. Esim. käyttäjien luonti suoraan XML kuvauksesta. AdminTool: Työkalu käyttäjien, yhteisöjen, palveluiden ja itse järjestelmän hallintaan. UserPortal: Loppukäyttäjälle suunnattu palvelu, jonka palvelut on rajattu käyttäjän itsenä muokkaamiseen. Lopullinen tuote: Ohjemisto kykenee muodostamaan virtuaaliyhteisöjä kuten vaadittu. Muodostaminen tapahtuu annettujen sääntöjen mukaan, jotka lopullisessa tuotteessa ovat yhteiseön oman profiilin ja valitun algoritmin yhdistelmä. Kommunikointi on toteutettu järjestelmän ytimessä vain siten, että kommunikointitietoja voidaan välittää (esim. sähköpostiosoite). Itse kommunikointtiin ei tarjota työkaluja. Demoportaaliin toteutettiin demona keskustelukanava, jossa jäsenet voivat keskustella keskenään. Kommunikointiosio jäi lopullisessa toteutuksessa myös sikäli puuttelliseksi, että koodi sisältää joitakin kovakoodattuja määrittelyjä, jotta järjestelmän demoaminen onnistuisi. Kommunikointi määriteltiin alunperinkin alhaiseksi prioriteetiksi, joten tätä totetutusta ei voida pitää mitenkään erityisen puuttellisena. Käyttäjien, palveluiden ja yhteisöjen lisääminen, poistaminen sekä muokkaaminen onnistuu helposti AMOK-rajapinnan kautta. Sekä portaali että hallintatyökalu käyttävät näitä onnistuneesti. Vaatimusmäärittelyssä esitettyä profiilien analysointia ei ole toteutettu siten, että ylläpitäjä voisi halutessaan käynnistää analyysin, joka johtaisi yhteisöjen muodostamiseen (tai tutkia miten yhteisöt voisivat muodostua). Sen sijaa liittämien läpinäkyvästi on toteutettu vaatimuksen mukaan. Järjestelmän toiminnan suunnittelua ja myöhempää toteutusta voidaan pitää sikäli onnistuneena, että alkuperäisen määrittelyn järjestelmä on saatu toteutettua. Se mikä ei kuitenkaan näy kirjoitetussa tekstissä on se, että ryhmällä oli kenties odotukset hieman
7(18) pidemmälle viedystä järjestelmästä, kuin ehdittiin lopulta toteuttaa. Alun perin järjestelmää suunniteltiin joustavaksi ja pääosin tässä on onnistuttukin. 2.2.4. Järjestelmän käytön periaattellinen toiminta Suurin osa järjestelmän toiminnosta muistuttaa toisiaan. Tässä on tehty pieni tarkastelu miten suunniteltu toiminta on propagoitunut lopulliseen koodiin ja sitä kautta tuotteeseen. Vaatimusmäärittely kuvaa perus user casen, jonka mukaan lähes kaikki toiminnallisen määrittelyn caset laadittiin. Vaatimusmäärittely: Kaikki ylläpidon ja käyttäjän toiminnot koskevat tietokantoihin tehtyjä muutoksia. Näitä ovat yleisellä tasolla uuden tiedon lisäys, olemassa olevan tiedon muokkaus ja olemassa olevan tiedon poisto Nämä kaikki voidaan esittää periaatteessa samanlaisen use case kuvauksen avulla: Esiehdot: Onko tieto jo olemassa? ON: EI: Toiminta: Hae tieto kannasta Luo uusi tietoalkio Poistetaanko tieto? KYLLÄ: EI: Jälkiehdot: Poista tieto kannasta Päivitä tai lisää parametreja, kunnes tiedot ovat oikeat. Lisää tieto kantaan. Tietokanta on konsistentti Toiminnallisen määrittelyn caset on kuvattu vastaavalla tavalla.
8(18) Toiminnallinen määrittely (esimerrki yhdestä toiminnasta): Toiminta: 1. Portaali tai Admin-sovellus lähettää pyynnön lisätä uusi käyttäjä järjestelmään. Pyyntö sisältää käyttäjän perustiedot ja käyttäjäkuvauksen. 2. AMOK tarkastaa ettei käyttäjätunnus ole käytössä. 3. AMOK lähettää VYM:lle pyynnön lisätä uusi käyttäjä kantaan. Pyyntö sisältää käyttäjän parametrit. 4. AMOK vastaanottaa paluuarvon, joka ilmoittaa, onko käyttäjän lisääminen kantaan onnistunut. Jälkiehdot: MAHDOLLISUUDET: - lisäys on onnistunut - tieto ei ole konsistenttia, käyttäjää ei ole lisätty kantaan - kantaan lisäys ei ole onnistunut - Käyttäjä on lisätty kantaan onnistuneesti - Lisäys ei ole onnistunut, tapauksesta informoidaan. Lopullinen tuote: Prosessi on aivan esitetyn mukainen sillä poikkeuksella, että AMOK ei tarkista onko tunnus jo olemassa, vaan VYM tekee tarkistuksen ja ilmoittaa siitä. Yleensä ottaen toiminnat on esitetty juuri niin kuin vaatimusmäärittelyn yleinen malli osoittaa. Lopullisen tuotteen ja toiminnallisen määrittelyn välillä on poikkeavuuksia sisäisellä tasolla eli esimerkiksi tietojen tarkistuksen yms. saattavat tapahtua eri tasolla kuin on määritelty. Tähän on johtanut ohjelmoinnin aikana huomatut ongelmat tai on vain todettu jonkun asian olevan järkevämpää toteuttaa muualla tai jotenkin eri lailla. Tällaisia muutoksia ei ole päivitetty takaisin toiminnaliseen määrittelyyn sillä tarkkuudella, kuin olisi pitänyt. Toiminnalisen määrittelyn toimintakuvauksissa on myös joitakin puutteita jälkiehtojen suhteen. Joissakin toiminnoissa ei ole määritelty siis sitä, mitä tulisi tapahtua jos joku menikin pieleen. Joitakin toimintoja ei oltu osattu määritellä toiminnaliseen määrittelyyn. Esimerkiksi käyttäjän luomisprosessi on sellainen, jonka toteutuksessa oli ryhmän sisällä ongelmia,
9(18) kun ei tiedetty tarkkaan miten prosessi kokonaisuudessaan etenee. Esimerkiksi käyttäjän lisäyksessä sanotaan että luonnin yhteydessä lähetetään käyttäjän parametrit. Käyttäjän parametreja on kuitenkin perustietojen (nimi, käyttäjätunnus) lisäksi käyttäjän ominaisuudet (profiili). Lopullinen toteutus toimii nyt niin, että käyttäjä luodaan ensin perustiedoilla ja sen jälkeen odotetaan, että käyttäjä päivittää (lisää) oman profiilinsa. Käytännössä käyttäjä saattaisikin kyllästyä profiilin täyttöönsä ja poistua palveluista, jolloin järjesetelmä sisältää epätäydellisen käyttäjän. Järjestelmän moduulien toteutusvaiheessa oli ongemia mm. siitä, että ei ollut yksimielisyyttä siitä voiko käyttäjää luoda ilman profiilia, mistä tyhjä oletusprofiili saadaan jne. Näitä asioita ei siis oltu oikein määritelty missään ja vaikka asioista sovittiinkiin yhteisissä kokouksisaa, niin määrittelyn puutteet näkyvät osin tuotetun koodin laadussa Pahimpana toiminnallisen määrittelyn ongelmana voisi pitää siis sitä, että kaikkia tehtyä muutoksia ja tarkennuksia ei ole saatu kirjattua vastaavaan dokumenttiin. 2.2.5. Ylläpidon toiminnat Vaatimumäärittely määrittelee ylläpidon toiminnot yleisellä tasolla. Vaatimusmäärittely: Ylläpidon tulee voida käyttää seuraavia toimintoja, jotta ohjelmistoa voidaan käyttää tarkoituksen mukaisesti. - Käyttäjäprofiilien poisto,luominen/muokkaus - Virtuaaliyhteisöjen luominen/muokkaus/poisto - Sääntöjen luonti ja muokkaus virtuaaliyhteisökohtaisesti - Käyttäjäprofiilien analysointi - Käyttäjien liittäminen/poisto yhteisöön/yhteisöstä - Kommunikaation järjestäminen virtuaaliyhteisön sisällä (prioriteetti 2) Toiminnallisessa määrittelyssä ei ole erikseen määritelty mikä on ylläpidon ja mikä jonkin muun käyttäjän toimintaa. Toiminnallinen määrittely kuvaa oikeastaan AMOKrajapinnan toimintaa, joka siis jakaa toiminnat palveluina ylöspäin. Esimerkiksi ylläpitoliittymä on tällainen. Toiminnaliseen määritelyn toiminnot (yksityiskohtia ei kopioitu tänne): lisää käyttäjä lisää palvelu lisää yhteisö
10(18) muokkaa käyttäjätieto (toiminnallinen määritely puhuu sekä käyttäjätiedoista, että profiilista samassa lauseessa) muokkaa yhteisötieto muokkaa palvelutieto poista käyttäjä poista yhteisö poista palvelu hae käyttäjät (kaikki) hae yhteisöt hae palvelut Teknisessä määrittelyssä on kuvattu AMOK luokkat UML kaavioin ja selityksin, josta käy ilmi toiminnalista määrittelyä vastaavat metodit ja tiedon esitysmuodot. Hallintatyökalu on varsinaisesti teknisen määrittelyn ulkopuolella, mutta hallintatyökalusta on laadittu oma lyhyt toimininnallinen ja tekninen kuvaus omaan muistioonsa. Projektisuunnitelmassa oli asiakkaan viidentenä tavoitteena eli vaatimusmäärittelyn priotiteettin nähden aika korkealle rankattu seuraava kommunikaation tavoite: Kommunikoinnin järjestäminen virtuaaliyhteisöjen välille (esim. e-mail, SMS, Chat) Demojen toteutus oli rankattu kuudenneksi tärkeimmäksi asiaksi: Käyttöliittymä (esim.demoportaali, demo administraattori käyttöliittymä) Lopullinen tuote (AMOK rajapinta + hallintatyökalu): Käyttäjien/palveluiden/yhteisöjen luonti/muokkaus/poisto on toteuttu. Yhteisön sääntöjen muokkaus on toteutettu yhteisön ominaisuuksien ja algoritmin määrittelyn yhdistelmänä. Säännöt eivät ole siis mitenkään erityinen tai erilainen asia verrattuna esim. käyttäjän ominaisuuksiin (profiiliin). Käyttäjäprofiilien analysointia ei ole toteutettu.
11(18) Käyttäjien/palveluiden liittäminen yhteisöihin on toteutettu sisäisesti (kun lasketaan yhteisöjen jäsenet), mutta tätä palvelua ei ole ulkoistettu (vaatisi jonkin verran lisätietoja mm. tietokantaan). Käyttäjäprofiilien analysointia ei ole toteutettu siten, että ylläpito voisi suorittaa analyyseja. Nyt järjestelmä analysoi vain sisäisesti muodostaessaan yhteisöjä. Kommunikaatiotiedot välitetään, mutta itse kommunikointi pitää järjestelmää VYM-coren ulkopuolella. Demoportaalissa ominaisuus toteutettiin chatboardina. Projektin ajankäyttöä tutkimalla voidaan todeta, että hallinatyökalu ja portaali saivat huomiota paljon tavoitteita enemmän. Liittymät ovat kuitenkin järjestelmän ainoita ulospäin näkyviä osia, joten kurssi asetti paineita niiden ylimääräiseen dokumentointiin ja testaamiseen. 2.2.6. Käyttäjän toiminnot Myös käyttäjien toimet oltiin erikseen llistattu vaatimusmäärittelyssä. Vaatimusmäärittely: - Hänen tulee voida kommunikoida muiden yhteisön jäsenten kanssa (prioriteetti 2) - Hänen tulee voida muokata omaa käyttäjäprofiiliaan - Hänen tulee voida tarkistaa, mihin yhteisöihin hän kuuluu - Hänen tulee rekisteröityä systeemiin ennen kuin voi hyödyntää yhteisöjä - Hänen tulee voida liittyä haluamiinsa virtuaaliyhteisöihin (prioriteetti 2) Toiminallisessa sekä teknisessä määrittelyssä ei ole käyttäjän toimintoja erikseen määritelty muuten, kuin AMOK-rajapinnan toimintana (ks. edellinen kappale) Lopullinen tuote (demoportaali): Kommunikointi toteutettiin portaalin ominaisuutena Käyttäjä voi muokata tietojaan. Käyttäjä näkee yhteisönsä Käyttäjän tulee rekisteröityä Käyttäjä ei voi liittyä haluamiinsa yhteisöihin, vaan on pakotettu pysymään niissä yhteisöissä joita järjestelmä tarjoaa (asiaan voi tosin vaikuttaa muokkamaalla ominaisuuksiaan).
12(18) 2.2.7. XML-tuki Jonkinlaista oikeata liittymää ulkoiseen maailmaan pidettiin tärkeänä heti vaatimusmäärittelyä luotaessa. Vaatimusmäärittely: Koska tietoa voidaan syöttää järjestelmään ja järjestelmästä voidaan haluta myös raportteja, tarvitaan syöttöön ja tulostukseen tarvittavat toiminnot. Syötteet luetaan tiedostosta ja raportit kirjoitetaan tiedostoihin. Esitystavaksi on valittu XMLkuvauskieli. - Käyttäjäprofiilien lataus/tallennus - Virtuaaliyhteisöjen lataus/tallennus Toiminnallinen määrittely viittaa asiaan vain lyheysti. Toiminnallinen määrittely: Sovellukseen tulee XML rajapinta muihin sovelluksiin, jonka kautta ne käyttävät VYM:n palveluita. Toiminnallinen määrittely ei sisällä erikseen use caseja XML rajapintatoeutuksen toiminnalle, mikä on periaatteessa puute. Toisaalta kyseessä on vain käyttäjien/palveluiden/yhteisöjen muokkaustoiminnat aivan samoin yksittäisissä muokkaustapauksissa, mutta muokkauksia tehdään XML kuvauksen pohjalta ja kenties useita perälläin. Teknisessä määrittelyssä on esitetty XML tietorakenteet DTD kuvauksina. Myös XML:n käsittelyyn liittyvien luokkien metodit on kuvattu. Tekninen määrittely: Tietoa VYM-järjestelmään voidaan syöttää tai lukea käyttäen suoraan AMOKrajapintaa, mutta vaihtoehtoisesti dataa voidaan välittää myös XML-kuvauksina. Tietorakenteet on esitetty luvussa 6. Lopullinen tuote: AMOK:n apuluokat sisältävät XMLReader ja XMLWriter luokat, joiden avulla XML esityksiä voi käsitellä helposti ja muuttaa esityksen VYM-järjestelmään sisäiseen esitysmuotoon. Hallintatyökalu sisältää tähän käyttöliittymän, jolla voi tuoda ja viedä sekä käyttäjiä, palveluita että yhteisöjä. XML tuki on periaatteessa määritelty ja toteutettu erinomaisesti, mutta toiminnalisen määrittelyn kantakuvaukseen ja XML DTD kuvaukseen oli päässyt lipsahtamaan virhe, joka vaikutti lopulliseen tuotteseenkin hieman ikävällä tavalla. DTD kuvausten mukaan
13(18) yhteisöillä ja käyttäjillä voi olla vain yksi tapa kommunikoida, mutta tietokannan mukaan niitä voi molemmilla olla useita. Järjestelmän sisäinen esitys on tämän hybridi ja tukee periaatteessa molempia! Käytännössä tuki on kuitenkin vain yhdelle kommunikointitavalle ja kantaan ei talleteta koskaan kuin yksi kommunikointitapa. VYM-rajapinta tarjoaa palvelun usean kommunikoinnin kyselyyn, mutta sitä se ei siis oikeasti toimi. Edellinen on oikeastaan ainut iso virhe, mitä suunnitelussa on tapahtunut. Jäljet olisivat olleet tuhoisia, jos kyseessä olisi ollut tärkeämn prioriteetin toiminto. Onneksi kommunikointi on määritelty pienemmän prioriteetin toiminnoksi, emmekä alkaneet todettua virhettä enää mitenkään korjaamaan teimme järjestelmään vain rumat hot fixit. 2.2.8. Oppiminen Vaatimusmäärittelyn tarkentavissa selityksissä mainitaan järjestelmän oppiminen. Vaatimusmäärittely: Käyttäjäprofiilien päivittämistarpeita voi syntyä, kun ohjelmistoa päivitetään kattamaan laajempia kokonaisuuksia. Sekundaarinen tarve, joka riippuu myös palvelusta, jonka toimintaa yhteisönmuodostajakone tukee, on saada järjestelmä tutkimaan ajon aikana virtuaaliyhteisön jäsenten toimia. Tällöin profiilia voitaisiin muokata automaattisesti (oppiminen, prioriteetti 2). Käyttäjäprofiileja voidaan myös poistaa, jos käyttäjä ei enää käytä palvelua (automaattinen poisto, prioriteetti 3). Myös toiminnallinen määrittely määrittelee oppimiseen liittyvät toiminnot: opeta systemiä (lisäykset, muokkaukset ja poistot, käyttäjän käyttäytyminen) Projektisuunnitelman mukaan opettaminen oli asiakkaan kuudenneksi tärkein tavoite: Systeemin automaattinen opettaminen Lopullinen tuote ei osaa opetusta, mutta opetus on kyllä huomioitu ratkaisuissa siten, että periaatteessa opetuksen toteuttaminen olisi mahdollista. Tämä vaatisi lähinnä palvelun lisäystä rajapintaan ja sellaisen koneen kirjoittamista joka osaisi hyödyntää tätä opetustietoa. Opettaminen on mainittu useassa kohtaa kakkosprioriteetin asiaksi ja projektin tavoitteista se on häntäpäässä, joten toteutuksen puuttumista ei voida katsoa epäonnistumiseksi. 2.2.9. Tietorakenteet Samaa tietoa kuvataan järjestelmän eri osissa eri tavoin. Vaatimusmääritely sisältää kuvauksen yleisellä tasolla.
14(18) Vaatimusmäärittely: Tietokannan tulee sisältää - käyttäjäprofiilit - virtuaaliyhteisöjen muodostamissäännöt - palveluiden profiilit - mahdollisesti jo muodostettujen virtuaaliyhteisöjen koostumus. Tätä voidaan tarvita laskentatehon säästämiseksi, mutta sitä joudutaan vastaavasti päivittämään säännöllisesti Toiminnallinen määrittely sisältää kannan kuvauksen, joka sisältää kaikki edelliset tiedot huomattavasti tarkennettua ja lisäksi tiedot kommunikaatiosta. Tekninen määrittely sisältää sekä XML kuvausten DTD määrittelyt sekä Java tietorakenteet. Kuten kappaleessa 2.2.7 on jo mainittu, niin tietorakenteiden suunnitteluvaiheessa tapahtuneen virheen takia kommunikaatiotiedot eivät ole konsistenssit. Ohessa esimerkkinä käyttäjän DTD kuvaus: <?xml version="1.0"?> <!ELEMENT PROFILELIST (PROFILE*)> <!ELEMENT PROFILE (FIRSTNAME,LASTNAME,USERID,COMMUNICATION,FEATURELIST)> <!ELEMENT FIRSTNAME (#PCDATA)> <!ELEMENT LASTNAME (#PCDATA)> <!ELEMENT USERID (#PCDATA)> <!ELEMENT COMMUNICATION (NAME (NAME,VALUE)>
15(18) <!ELEMENT FEATURELIST (FEATURE+) <!ELEMENT FEATURE (NAME,NUMBER)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT VALUE (#PCDATA)> <!ELEMENT NUMBER (#PCDATA)> Tätä kommunikaation kommunikaatiovirhettä lukuunottama tietorakenteet on esitetty kaikissa suunnitelmissa jo lopullisessa tuotteessa asianmukaisesti ja juuri niin, kuin tekninen määrittely ne luokkakuvauksissaan määrittelee. 2.2.10. Suorituskyky, turvallisuus, luotettavuus Vaatimusmäärittely ei aseta tuotteelle juurikaan suorituskyky-, turvallisuus- tai luotettavuusvaatimuksia. Olisikin ollut lähes mahdotonta vielä keretä suunnittelemaan ja toteuttamaan tällainen kokeellinen järjestelmä siten, että kaikki suorituskysy, turvallisuus yms. normaalit vaatimukset olisivat olleen mukana. Lopullista tuotetta ei ole testattu suorituskyvyn kannalta, mutta toteutetun järjestelmän ominaisuuksiasta voidaan todeta se, että se ei tule toimimaan hyvin kuin pienillä käyttäjämäärillä. Turvallisuus ja luotettavuusasiat on jätetty suosiolla toteutuksen ulkopuolelle. 2.2.11. Ylläpidettävyys, siirrettävyys Vaatimumäärittely vaati ylläpidettävyydeltä ainostaan XML tuen ja jonkinlaisen ylläpitoa demoavan järjestelmän. Siirrettävyysvaatimus todettiin tulevan automaattisesti Java-toteutuksella. Lisäksi mainitaan, että järjestelmän tulee toimia useissa ympäristöissä. Projektisuunnnitelmassa asialle on annettu enemmän arvoa (2. tärkein tavoite): Arkkitehtuuri mahdollista systeemin liittämisen minkä tahansa (WAP,Web, SMS) portaalin yhteyteen. Standardi rajapinta. Paljon alhaisempi tavoite (järjestyksessä seitsämäs) oli seuraava: Systeemin laajentamisen mahdollistaminen projektin jälkeen Lopullinen tuote sisältää vaaditut ylläpito-ominaisuudet ja eiryisesti XML tuen. Sen lisäksi että koodi on Java kielellä tehtyä ja siirrettävää, se pyrkii olemaan mahdollisimman modulaarista ja helposti laajennettavaa. AMOK ja VYM rajapinnat pyrkivät olemaan mahdollisimman helppokäyttöiset ja selkeät ja ne on dokumentoitu hyvin. Jos VYM olisi todellinen tuote, olisi rajapinnat ehkä olleet aitoja CORBA rajapintoja puhtaiden Java rajapintojen sijaan, joten liittymärjapinta voisi olla avoimempikin. Demoluontoisesti olemme rakentaneet sekä toimivan portaalin, että hallintatyökalun joka on lienee riittävä osoitus siitä, että systeemi voidaan liittää mihinkä yhteyteen tahansa.
16(18) 2.3. Todetut suunnittelun ja toteutuksen puutteet Tässä luvussa on kommentteja dokumentoinnin ja toteutuksen puutteista. Osaan näistä on saatettu viitata aiemmissa katselmuksen osissa. 2.3.1. Käyttäjien/palveluiden/yhteisöjen ominaisuudet Ominaisuuksien suunnittelussa ja toteutuksessa oli joitakin ongelmia. Jo aiemmin mainittiin luvussa 2.2.5, kuinka käyttöprofiilin ja perustietojen jakamisessa ja niiden asettamisessa oltiin toteutusvaiheessa erimielisiä suunnittelun puutteiden takia. Myös tyhjien piirteiden hakeminen käyttöliittymään (esim. portaaliin, joka ei voi profiilin rakennetta itse tietää) oli ongelma, johon lopulta löydettiin kohtuullisesti toimiva ratkaisu. Ratkaisun ongelma on se, että piirteistä tuli järjestelmän sisällä ikään kuin kiinteitä ja niitä ei voi päivittää dynaamisesti. Siis VYM-rajapinta ei tarjoakaan piirteitä mielensä mukaan, vaan piirteet on listattu ja siten rajattu ui.xml kirjoitettuun muotoon. Korostetaan nyt vielä että piirrelista on edelleen sikäli dynaaminen, että piirrelistaa voi muuttaa ui.xml:ää muuttamalla. Ongelma on vain se, että uudet piirteet eivät kuitenkaan päivity jo järjestelmässä oleviin käyttäjiin ja johtaa lopulta siihen että systemistä tulee käyttökelvoton. Siis piirteitä voidaan muuttaa, mutta kaikkai käyttäjän on luotava uudestaan. Itse koodia tai kantaa ei tarvitse tietenkään muuttaa. Piirteisiin liittyvät asiat olisi pitänyt sunnitella huolellisemmin, niin ongelmilta olisi vältytty. 2.3.2. Tietojen tarkistaminen Toiminnallisessa määrittelyssä on ylimalkaisesti kuvattu missä tietoja tarkistetaan. Käytännössä tietorakenteiden ja sisältöjen tarkistamien olisi pitänyt suunnitella paremmin. Nyt vähän jokainen luokka tarkistaa, onko esim. käyttäjän tiedot oikein ja mikään ei tee sitä tarkistusta kuitenkaan täydellisesti. Olisi siis pitänyt määritellä esim. että luokkaa ei pysty alustamaan väärillä/puuttellisilla tiedoilla ja että VYM rajapinta tarkistaa sellaiset tiedot mitä luokka itse ei voi tarkistaa (onko vaikka käyttäjätunnus varattu) ja sitten olisikin voitu olettaa tietojen olevan kunnossa kun sitä välitetään eteenpäin. Eli esim. VYM-kone voisi aina olettaa tiedon olevan sallittua. 2.3.3. VYM koneen toiminta VYM-kone oli ensin ajateltu sellaiseksi, että se pyörisi omassa serveriprosessaan ja portaalin käyttäjät, administraattorit yms. pyytävät palvelimelta haluamiaan palveluja. Nyt toteutus on kuitenkin sellainen, että esim. portaalin prosesseissa jokainen käyttäjä luo aina uuden VYM-koneen loggautuessaan sisään. Tämä ei taatusti ole tehokasta ja aiheuttaa muitakin ongelmia: Tietojen muutoksiin ei lukkoja tai muita mekanismeja, jotka estäisivät kahta eri käyttäjää sotkemasta toisen toimintaa. Esim. nyt toinen käyttäjä voi poistaa samaan aikaan kun toinen (vaikkapa hallintatyökalun käyttäjä) muokkaa käyttäjää. Kun tietoja sitten yritetään tallentaa päädytään jonkinlaiseen
17(18) 3. Yhteenveto virhetilanteeseen. Tietokannan transaktio-ominaisuudet takaavat onneksi sen, että järjestelmää ei voi saada kuitenkaan täysin sekaisin. Yhteisöjen laskenta tapahtuu aina kun käyttäjä/administraattori muuttaa omiaisuustietoja. Jos käyttäjiä ja yhteisöjä on paljon ja käytössä on laskentatehoa vaativia algoritmeja, niin käyttäjä joutuu odottamaan tietoa profiilin päivityksestä niin kauan kun kaikki yhteisöt on laskettu uudelleen. Tekninen määrittely vastaa täysin toteutusta, joten itse toteutusta ei voida kuitenkaan tämän takia pitää mitenkään puuttellisena. 2.3.4. Tekninen suunnittelu Joitakin moduuleja tai moduulien osia ei ole suunniteltu lainkaan. Esim. demoportaalin osalta tämä on ymmärrettävää, koska koko sovelluksen ideana oli demota VYMjärjestelmän käyttöä. VYM:n sisäisissä rakenteissa tämä on puolestaan selvä puute. Nekin osat, joita on suunniteltu, on osin selvästi suunniteltu enemmänkin yritys-erehdys periaattella eikä selkeitä suunnitelun menetelmiä käyttäen. Esim. UML prosessia on projektissamme käytetty, mutta sitä olisi ehkä voinut käyttää järjestelmällisesti koko tuotekehityksen ajan. Toisaalta tämä ongelma on hyvin yleinen softa-alalla. Toiminnallisesta määrittelystä aletaan liian nopeasti kirjoitaamaan suoraan koodia. Taitavilta ohjelmoijilta jälki voi olla hyvääkin, minkä huomaa meidänkin lähdekoodeja ja itse ohjelman toimintaa tarkasteltaessa. Projektin koon kasvaessa on vaarana, että suunnittelun puute johtaa epäyhteensopivaan koodiin, korjauskierteeseen ja lopulta laaduttomaan koodiin. 3.1. Ominaisuuksien toteutuminen 3.1.1. Ominaisuudet, jotka on toteutettu kuten suunniteltu Valtaosa ominaisuuksista toteutettiin niikuin oli suunniteltu. Kaikki lisäys/poisto/muokkausominaisuudet sekä VYM-koneen perustoiminnot toteutettiin suunnitelmien mukaan. Suunnitelmissa ja toteutuksissa on tietenkin parantamisen varaa, mutta mikään ei voi tietenkään olla täydellistä 3.1.2. Ominaisuudet, jotka puuttuvat kokonaan Primäärivaatimuksia ei puutu lainkaan. Sekundäärivaatimuksista puuttuvat kokonaan vain koneen opettaminen sekä mahdollisuus suorittaa analyyseja käyttäjäprofiileista. 3.1.3. Ominaisuudet, jotka on toteutettu puutteellisesti tai väärin Pieniä puutteita voi listata paljonkin (ks. luku 2.3), mutta tässä lista vain selkeimmistä puutteista tai virheistä:
18(18) Kommunikaatiot määritelty eri tavoin toiminnallisessa ja teknisessä määrittelyssä. Koodissa toteutettu näiden hybridi. Kommunikointiominaisuudet on hardkoodattu koodiin, jotta demo toimisi. Systeemin opettamista ei toteutettu. Tietorakenteiden arvoalueita ja tarkistuksia ei määritelty. Koodissa tarkistuksia tehdään siellä täällä. Ominaisuuslistoja ja käyttäjän perustietoja ei ole eroteltu riittävästi suunnittelussa. Ohjelmakoodissa nämät ovat selkeästi eri asoita. Vakavimmat puuttet ovat onneksemme (tai hyvyyttämme) sekundäärivaatimuksiin liittyviä. 3.1.4. Ominaisuudet, jotka on toteutettu, mutta ei suunniteltu Ryhmäämme ei voi juurikaan syyttää siitä, että olisi lähdetty toteuttamaan suunnittelemattomia ominaisuuksia. Ehkä ainut ylimääräinen ominaisuus löytyy XML tiedostojen tuonnista, jossa hallintatyökalu yrittää toipua virhetilanteesta jatkamalla tiedoston lukemista, mutta XMLReader luokkaa ei oltu suunniteltu tällaisia tilanteita varten, joten ominaisuus toimii miten sattuu. Ylimääräistä ovat tietysti myös kommunikoinnin käsittely kahdessa eri paikassa VYM-rajapintaa. Sen sijaan lopulliseen koodiin tehtiin joitakin sellaisia asioita, joita ei välttämättä selkeästi löydy suunnitteludokumenteista. Tällöin on kyseessä ollut suunnittelun puutteita, joita on pyritty ratkomaan kokouksissa ja pienemmissä tapauksissa omatoimisestikin. 3.2. Loppukommentti Vaikka kommentteja ja pieniä puutteita löytyikin paljon, voi projektin läpiviemistä pitää silti onnistuneena. Lisää painoarvoa edelliselle lauseelle antaa se, jos verrataan projektisuunnitelmassa esitettyjä tavoitteita saavutettuihin tavoitteesiin ja toisaalta tarkastellaan sitä, missä tavoitteissa on eniten puutteita tärkeissä tavoitteissa on yleensä vähemmän puutteita kuin listan vähemmän tärkeissä tavoitteissa. Silti pitää vielä korostaa ja harmitella sitä, että tärkeimmän tavoitteen toteutuminen ei ollut niin hyvää kuin ryhmä itsekkin kunnianhimoisesti tavoitteli. Osan syystä voi vierittää meidänkin ryhmää koskevaan aivan luonnolliseen tosiasiaan, eli ohjelmistoprojektin läpiviemisestä ei ole riittävää kokemusta sitä on kuitenkin opittu, ja se lienee ollut tarkoituskin. Kyllästymiseen asti pitää myös todeta se totuus, että kurssin vaatimukset eivät sopineet projektin tavoitteisiin! Tästäkin huolimatta ryhmä kykeni tuottamaan kohtuullisesti tutkimusta ja tulevaisuudennäkymiä, liiankin hyvin toimivat demot sekä kiloittain aiheiseen liittyvää laadukasta dokumentaatiota.