LAATUKATSELMUS LU Virtuaaliyhteisöjen muodostamien Saved
|
|
- Teija Salo
- 8 vuotta sitten
- Katselukertoja:
Transkriptio
1 1(18) JAKELU Koko VYM-ryhmä Vers Muuttaja Pvm Muutos Tarkastanut Hyväksynyt Alkuperäinen versio Luonnos 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 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ä Katselmuksen tulokset 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 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 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 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 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 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 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 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 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 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 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 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 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. , 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 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 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 12(18) 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 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 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 Tietorakenteet Samaa tietoa kuvataan järjestelmän eri osissa eri tavoin. Vaatimusmääritely sisältää kuvauksen yleisellä tasolla.
14 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 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 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 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 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 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 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 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 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 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 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 Ominaisuuksien toteutuminen 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ä Ominaisuudet, jotka puuttuvat kokonaan Primäärivaatimuksia ei puutu lainkaan. Sekundäärivaatimuksista puuttuvat kokonaan vain koneen opettaminen sekä mahdollisuus suorittaa analyyseja käyttäjäprofiileista 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(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ä 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 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.
VAATIMUSMÄÄRITTELY Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 4)
VAATIMUSMÄÄRITTELY Versio 1.0 (luonnos 4) Edited by Checked by Approved by Juha Parhankangas Luonnos 4 i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. JOHDANTO 2 1.1. Projektin luonne 2 1.2. Tarkoitus ja kattavuus
LisätiedotVAATIMUSMÄÄRITTELY Virtuaaliyhteisöjen muodostaminen Versio 1.2
VAATIMUSMÄÄRITTELY Edited by Checked by Approved by Antti Tuomaala Juha Parhankangas Niko Stenberg i Sisällysluettelo DOKUMENTIT VERSIOT 1 1. JOHDANTO 2 1.1. Projektin luonne 2 1.2. Tarkoitus ja kattavuus
LisätiedotTEKNINEN MÄÄRITTELY Virtuaaliyhteisöjen muodostaminen Versio 1.0 (Luonnos 2)
TEKNINEN MÄÄRITTELY Edited by Checked by Approved by Tuomo Marttila Luonnos 1 Tekninenmäärittely i Sisällysluettelo 1. JOHDANTO 2 1.1. Tarkoitus ja kattavuus 2 1.2. Tuote ja ympäristö 2 1.3. Määritelmät,
LisätiedotTOIMINNALLINEN MÄÄRITTELY Virtuaaliyhteisöjen muodostaminen Versio 1.0
TOIMINNALLINEN MÄÄRITTELY Versio 1.0 Edited by Checked by Approved by Tuomo Marttila Juha Parhakangas Toiminnallinenmäärittely i Sisällysluettelo 1. JOHDANTO 2 1.1. Tarkoitus ja kattavuus 2 1.2. Tuote
LisätiedotTOIMINNALLINEN MÄÄRITTELY MS
TOIMINNALLINEN MÄÄRITTELY 11.11.2015 MS YLEISTÄ 1/2 jäsennelty etenee yleiskuvauksesta yksityiskohtiin kieliasultaan selkeä kuvaa myös tulevan järjestelmän ympäristöä tarpeellisella tarkkuudella kuvaa
LisätiedotEDISTYMISRAPORTTI - T4 Virtuaaliyhteisöjen muodostaminen Versio 1.0
EDISTYMISRAPORTTI - T4 Edited by Checked by Approved by Antti Tuomaala Harri Kauhanen i Sisällysluettelo DOKUMENTIN VERSIOT 2 1. PROJEKTIN TILA 3 2. SUORITETUT TEHTÄVÄT 5 Projektisuunnitelma 5 Testaussuunnitelma
LisätiedotYlläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari
LisätiedotEDISTYMISRAPORTTI - T2 Virtuaaliyhteisöjen muodostaminen Versio 1.2
EDISTYMISRAPORTTI - T2 Edited by Checked by Approved by Antti Tuomaala Harri Kauhanen i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. PROJEKTIN TILA 2 1.1. Yleistä 2 1.2. Resurssit 2 1.3. Laatu 4 2. SUORITETUT
LisätiedotTämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:
Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus
LisätiedotTESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - VYM JA KANTA Versio 1.0 i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen
LisätiedotTESTIRAPORTTI - JÄRJESTELMÄ, ADMIN Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - JÄRJESTELMÄ, ADMIN i Sisällysluettelo DUMENTIN VERSIOT 1 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI
LisätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
LisätiedotOhjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
LisätiedotEDISTYMISRAPORTTI - T1 Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 1)
EDISTYMISRAPORTTI - T1 Edited by Checked by Approved by Antti Tuomaala i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. PROJEKTIN TILA 2 2. SUORITETUT TEHTÄVÄT 4 Projektisuunnitelma Vaatimusmäärittely Virhe.
LisätiedotVaatimusmäärittely Ohjelma-ajanvälitys komponentti
Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit
LisätiedotTESTIRAPORTTI - XMLREADER-LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 2)
TESTIRAPORTTI - XMLREADER-LUOKKA Versio 1.0 (luonnos 2) Copyright Comptel Oyj i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin
LisätiedotTESTIRAPORTTI - XMLREADER LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - XMLREADER LUOKKA i Sisällysluettelo 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI 3 2.1. Testauksen
LisätiedotOhjelmoinnin perusteet Y Python
Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2009 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2009 1 / 28 Puhelinluettelo, koodi def lue_puhelinnumerot(): print "Anna lisattavat nimet ja numerot." print
LisätiedotHallintaliittymän käyttöohje
Hallintaliittymän käyttöohje 1. Yleisiä huomioita Hallintaliittymän käyttöä helpottavia yleisiä huomioita: - Käytä listanäkymien hakukentissä kentän vieressä olevaa hakunappia, älä enter-näppäintä. - Älä
LisätiedotArkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14
Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2
LisätiedotTESTIRAPORTTI - JÄRJESTELMÄ, PORTAL Virtuaaliyhteisöjen muodostaminen Versio 1.0
TESTIRAPORTTI - JÄRJESTELMÄ, PORTAL i Sisällysluettelo DUMENTIN VERSIOT 1 1. YLEISTÄ 2 1.1. Dokumentin tarkoitus ja yleisiä toimintaohjeita 2 1.2. Viittaukset muihin dokumentteihin 2 2. SUORITETTAVA TESTI
LisätiedotPalautuskansio moduuli, ja sen vuorovaikutukset tehtävien annossa!
Palautuskansio moduuli, ja sen vuorovaikutukset tehtävien annossa! - Elikkä tässä ohjeessa näet kuinka voit tehdä peda.net palveluun koti/etätehtäviä tai vaikka kokeitten tekoa, tapoja on rajattomasti.
LisätiedotDigi-tv vastaanottimella toteutetut interaktiiviset sovellukset
Tekninen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Sisällysluettelo 1. Johdanto...4 1.1. Tarkoitus ja kattavuus...4 1.2. Tuote ja ympäristö...4 1.3. Määritelmät,
LisätiedotVaatimusmääritelystä UML:n avulla
Vaatimusmääritelystä UML:n avulla Mitä käyttötapauskaaviolla voi kuvata? Mitkä ovat sen keskeiset elementit? Miten laaditaan käyttötapauskaavio? Miksi laaditaan kirjallisia kuvauksia? Miksi käyttötapaukset
LisätiedotT Testiraportti - järjestelmätestaus
T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria
LisätiedotJärjestelmäarkkitehtuuri (TK081702)
Järjestelmäarkkitehtuuri (TK081702) yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,
LisätiedotBlueJ ohjelman pitäisi löytyä Development valikon alta mikroluokkien koneista. Muissa koneissa BlueJ voi löytyä esim. omana ikonina työpöydältä
Pekka Ryhänen & Erkki Pesonen 2002 BlueJ:n käyttö Nämä ohjeet on tarkoitettu tkt-laitoksen mikroluokan koneilla tapahtuvaa käyttöä varten. Samat asiat pätevät myös muissa luokissa ja kotikäytössä, joskin
LisätiedotLyseopaneeli 2.0. Käyttäjän opas
Lyseopaneeli 2.0 Käyttäjän opas 1. Esittely Lyseopaneeli on Oulun Lyseon lukion käyttäjätietojen hallintapalvelu jonka tarkoitus on niputtaa yhteen muutamia oleellisia toimintoja. 2. Yleistä paneelin käytöstä
Lisätiedot1 JOHDANTO...2 2 UUDEN ILMOITUKSEN LUOMINEN...2 3 VALMIIN ILMOITUKSEN MUOKKAAMINEN...4 4 YLEISTEKSTIEN KÄYTTÖ JA LUOMINEN...4
Päivitetty 27.4.2010 Sisällysluettelo 1 JOHDANTO...2 2 UUDEN ILMOITUKSEN LUOMINEN...2 3 VALMIIN ILMOITUKSEN MUOKKAAMINEN...4 4 YLEISTEKSTIEN KÄYTTÖ JA LUOMINEN...4 5 SAAPUNEET HAKEMUKSET JA NIIDEN KÄSITTELY...4
LisätiedotMiten hyväksyn SoleOPSissa opiskelijat omalle opintojakson toteutukselle?
Miten hyväksyn SoleOPSissa opiskelijat omalle opintojakson toteutukselle? Syksystä 2014 lähtien uusien aloittavien vuosikurssien osalta opintojakson toteutukselle ilmoittautuneiden opiskelijoiden hyväksyminen
LisätiedotEDISTYMISRAPORTTI - PS Virtuaaliyhteisöjen muodostaminen Versio 1.0
EDISTYMISRAPORTTI - PS Edited by Checked by Approved by Antti Tuomaala Harri Kauhanen i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. PROJEKTIN TILA 2 2. SUORITETUT TEHTÄVÄT 3 Projektisuunnitelma 3 Vaatimusmäärittely
LisätiedotKuopio Testausraportti Asiakkaat-osakokonaisuus
Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki
LisätiedotT Projektikatselmus
T-76.115 Projektikatselmus Projektityöryhmä GenCode I3-iteraatio 17.3.2004 Agenda Tavoitteiden toteutuminen (5 min) Resurssien käyttö (5 min) Iteraation tulokset (10 min) Riskit (5min) +Kokemuksia työskentelymenetelmistä
Lisätiedot<e.g. must, essential, conditional>
Käyttötapaukset Kurssin malli käyttötapauksille: Tila < List of users and the other systems that interacts directly with a system>
LisätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu KÄYTTÖOHJE. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu JÄRJESTELMÄN KÄYTTÖOHJE LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001
Lisätiedot17/20: Keittokirja IV
Ohjelmointi 1 / syksy 2007 17/20: Keittokirja IV Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/10 Tavoitteita
LisätiedotT Testiraportti - integraatiotestaus
T-76.115 Testiraportti - integraatiotestaus 16. huhtikuuta 2002 Confuse 1 Tila Versio: 1.1 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 16.04.2002 Jani Myyry Versiohistoria
LisätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
LisätiedotYlläpitodokumentti Mooan
Ylläpitodokumentti Mooan Helsinki 16.08.06 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op/6ov) Projektiryhmä Heikki Aitakangas
LisätiedotUutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3
Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2
LisätiedotOppilaan opas. Visuaaliviestinnän Instituutti VVI Oy. Versio 0.2 (2008-01-21)
Oppilaan opas Visuaaliviestinnän Instituutti VVI Oy Versio 0.2 (2008-01-21) Versio Päivämäärä Kuvaus 0.1 2005-01-16 Ensimmäinen versio. 0.2 2008-01-21 Korjattu kuvatiedostojen maksimiresoluutio ja muutamia
LisätiedotMenetelmäraportti - Konfiguraationhallinta
Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1
LisätiedotEMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008. Meeri Nieminen
EMCS-järjestelmän sanomarajapinnan toiminnallinen kuvaus asiakkaille 13.6.2008 Meeri Nieminen Asiakkaan vaihtoehdot Asiakkaan vaihtoehdot EMCS-järjestelmän käyttöön XML-sanomarajapinta oman järjestelmän
LisätiedotTarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen
Tarjolla tänää: Ohjelmiston toteutuksesta JOT2007 CRC-kortit Testilähtöinen kehittäminen Uudelleenrakentaminen Voisiko ohjelmointi olla sittenkin suunnittelua? Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit
LisätiedotMaastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla
Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla Viimeksi muokattu 5. toukokuuta 2012 Maastotietokannan torrent-jakeluun sisältyy yli 5000 zip-arkistoa,
LisätiedotTulosta yrityksesi tuloslaskelma ja tase myöhempää tarkastusta varten. Ota varmuuskopio tilanteesta ennen tilimuunnosta.
Tilimuunnosohje 1 (5) Tilimuunnosajo Tilimuunnosajo täytyy tehdä jos halutaan vaihtaa yritykselle tilikartta ja säilyttää tilien tapahtumat. Tilikartan vaihtoa varten perustetaan uusi yritys, jonne muunnosajossa
LisätiedotOhje 1 (12) Maarit Hynninen-Ojala MOODLE PIKAOHJE. Kirjautuminen Moodleen ja työtilan valitseminen
Ohje 1 (12) Maarit Hynninen-Ojala MOODLE PIKAOHJE Kirjautuminen Moodleen ja työtilan valitseminen 1. Verkko-osoite: http://moodle.metropolia.fi 2. Kirjautuminen: omat verkkotunnukset 3. Oma Moodlessa näkyvät
LisätiedotKortinhaltijat joilla on maksukeskeytys Maksuryhmään liitettyjen kortinhaltijoiden lukumäärä, joiden maksut ovat tilapäisesti keskeytetty.
1(6) MAKSURYHMÄN HALLINTA Maksuryhmäkohtaiselle sivulle pääset klikkaamalla yksittäisen maksuryhmän nimeä verkkopalvelun etusivulla tai valitsemalla ryhmän Maksuryhmät - osion listalta. Sivun tiedot ja
LisätiedotOhjelmiston toteutussuunnitelma
Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,
LisätiedotKÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014. Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0
KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014 Käyttäjätutkimus ja käsitteellinen suunnittelu Järjestelmän nimi versio 1.0 Jakelu: Tulostettu: 201543 Samuli Hirvonen samuli.hirvonen@student.tut.fi
LisätiedotDoodle helppoa aikatauluttamista
Doodle helppoa aikatauluttamista Kuinka käytän Doodlea? -vaiheittainen opas käyttöön ja aikataulukyselyn luomiseen http://www.doodle.com/ Doodle on ohjelma joka auttaa sinua aikatauluttamaan kokouksia
LisätiedotBLOGGER. ohjeita blogin pitämiseen Googlen Bloggerilla
BLOGGER ohjeita blogin pitämiseen Googlen Bloggerilla Sisältö Blogin luominen... 1 Uuden blogitekstin kirjoittaminen... 4 Kuvan lisääminen blogitekstiin... 5 Lisää kuva omalta koneelta... 6 Lisää kuva
LisätiedotTEKNINEN MÄÄRITTELY Virtuaaliyhteisöiden muodostaminen Versio 1.2
TEKNINEN MÄÄRITTELY Versio 1.2 Edited by Checked by Approved by Harri Kauhanen Tuomo Marttila i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. JOHDANTO 2 1.1. Tarkoitus ja kattavuus 2 1.2. Tuote ja ympäristö
LisätiedotOpponointitestaus VYM -> LiKe 29.03.2001
Opponointitestaus VYM -> LiKe 29.03.2001 Opponoinnin testitapaukset Opponoinnin testitapaukset on pääosin suoritettu loggautumalla sisään käyttäjällä Minna Reino, joka on I -käyttäjä After Sales-projektissa.
LisätiedotWebforum. Version 14.4 uudet ominaisuudet. Viimeisin päivitys: 2014-12-6
Webforum Version 14.4 uudet ominaisuudet Viimeisin päivitys: 2014-12-6 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Yleistä & hallinnointi... 5 Dokumentit... 5 Perättäinen tarkistus- ja hyväksymisprosessi...
LisätiedotConcurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo
Concurrency - Rinnakkaisuus Group: 9 Joni Laine Juho Vähätalo Sisällysluettelo 1. Johdanto... 3 2. C++ thread... 4 3. Python multiprocessing... 6 4. Java ExecutorService... 8 5. Yhteenveto... 9 6. Lähteet...
LisätiedotOhjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus
Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright
Lisätiedot58160 Ohjelmoinnin harjoitustyö
58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista
LisätiedotWritten by Administrator Monday, 05 September 2011 15:14 - Last Updated Thursday, 23 February 2012 13:36
!!!!! Relaatiotietokannat ovat vallanneet markkinat tietokantojen osalta. Flat file on jäänyt siinä kehityksessä jalkoihin. Mutta sillä on kuitenkin tiettyjä etuja, joten ei se ole täysin kuollut. Flat
LisätiedotRekursiolause. Laskennan teorian opintopiiri. Sebastian Björkqvist. 23. helmikuuta Tiivistelmä
Rekursiolause Laskennan teorian opintopiiri Sebastian Björkqvist 23. helmikuuta 2014 Tiivistelmä Työssä käydään läpi itsereplikoituvien ohjelmien toimintaa sekä esitetään ja todistetaan rekursiolause,
LisätiedotGood Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi
Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006-11-25 Janne Mäkelä Alustava 1.0 2006-12-10 Janne Mäkelä Valmis 1.
LisätiedotTikon ostolaskujen käsittely
Toukokuu 2013 1 (7) 6.3.0 Copyright Aditro 2013 Toukokuu 2013 2 (7) Sisällysluettelo 1. Käyttäjäasetukset... 3 2. Yleiset parametrit... 3 3. Kierrätysasetukset... 3 4. palvelimen tiedot... 4 5. lähetyksen
LisätiedotEnsimmäisessä vaiheessa ladataan KGU tietokanta Hallitse tietokantoja toiminnon avulla.
1 Odoo ohjelman demokäyttöön riittää, että asentaa ohjelmiston, ja tietokannan. Jos päättää ottaa ohjelmiston tuotannolliseen käyttöön, on päivitettävä myös XML raporttipohjat, sekä syötettävä yrityksen
LisätiedotTapahtumakalenteri & Jäsentietojärjestelmä Ylläpito
Tapahtumakalenteri & Jäsentietojärjestelmä Ylläpito Henri Kinnunen, Seppo Tompuri, Tero Malkki, Matti Heiskanen, Tommi Rönkönharju, Tuomas Valkeapää Sisällysluettelo 1. Alkusanat.2 2. Asennusohje..2 3.
Lisätiedot1. ASIAKKAAN OHJEET... 2. 1.1 Varauksen tekeminen... 2. 1.2 Käyttäjätunnuksen luominen... 4. 1.3 Varauksen peruminen... 4
1. ASIAKKAAN OHJEET... 2 1.1 Varauksen tekeminen... 2 1.2 Käyttäjätunnuksen luominen... 4 1.3 Varauksen peruminen... 4 1.4 Omien tietojen muokkaaminen... 5 1.5 Salasanan muuttaminen... 5 2. TYÖNTEKIJÄN
LisätiedotTietokannan luominen:
Moodle 2 Tietokanta: Tietokanta on työkalu, jolla opettaja ja opiskelijat voivat julkaista tiedostoja, tekstejä, kuvia, linkkejä alueella. Opettaja määrittelee lomakkeen muotoon kentät, joiden kautta opiskelijat,
LisätiedotTietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto
LisätiedotAsiakaspalveluprosessin kehittäminen jakelun vaikutuspiiriin kuuluvien asioiden osalta
Asiakaspalveluprosessin kehittäminen jakelun vaikutuspiiriin kuuluvien asioiden osalta Tehtävät 1. Asiakaspalvelun ja asiakkaiden vaatimukset jakelulle => haastateltavat organisaatiot/henkilöt => lukijaraatien
LisätiedotIkivihreä kirjasto loppuraportti määrittelyprojektille
loppuraportti määrittelyprojektille Mikkelin Ammattikorkeakoulu Oy Sähkö ja informaatiotekniikan laitos Versiomuutokset 29.1.2014 viimeisin tilanne tietokantakonversiosta Mirja Loponen 7.2.2014 tarkennettu
LisätiedotSuunnitteluvaihe prosessissa
Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet
LisätiedotAnalyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio
Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia
LisätiedotVIENET JULKAISUJÄRJESTELMÄLLÄ TOTEUTETTUJEN INTERNET-SIVUJEN YLLÄPITO-OHJE
VIENET JULKAISUJÄRJESTELMÄLLÄ TOTEUTETTUJEN INTERNET-SIVUJEN YLLÄPITO-OHJE JULKAISUJÄRJESTELMÄÄN KIRJAUTUMINEN. Osoitekenttään kirjoitetaan www.domain.fi/admin. Kirjoita käyttäjätunnus: xxxxxx. Salasana:
LisätiedotAutomaattinen yksikkötestaus
Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä
LisätiedotSisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology
LisätiedotTikon ostolaskujen käsittely
Toukokuu 2014 1 (8) Toukokuu 2014 2 (8) Sisällysluettelo 1. Käyttäjäasetukset... 3 2. Yleiset parametrit... 3 3. Kierrätysasetukset... 3 4. palvelimen tiedot... 4 5. lähetyksen aktivointi... 5 6. Eräajot
LisätiedotELM GROUP 04. Teemu Laakso Henrik Talarmo
ELM GROUP 04 Teemu Laakso Henrik Talarmo 23. marraskuuta 2017 Sisältö 1 Johdanto 1 2 Ominaisuuksia 2 2.1 Muuttujat ja tietorakenteet...................... 2 2.2 Funktiot................................
LisätiedotYlläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito
Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective) testausvaiheessa
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite
LisätiedotSALITE.fi -Verkon pääkäyttäjän ohje
SALITE.fi -Verkon pääkäyttäjän ohje Sisältö 1 Verkon pääkäyttäjä (Network Admin)...3 2 Verkonhallinta...3 2.1 Navigointi verkonhallintaan...3 2.2 Sivustot...3 2.1 Sivustojen toiminnot...4 2.3 Sivuston
LisätiedotSoft QA. Vaatimusten muutostenhallinta. Ongelma
Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei
LisätiedotSubversion-ohje. Linux Traffic Control-käyttöliittymä Ryhmä paketti2
Subversion-ohje Linux Traffic Control-käyttöliittymä Ryhmä paketti2 Helsinki 1.11.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti
LisätiedotTestaussuunnitelma. PUSU-ryhmä. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma PUSU-ryhmä Helsinki 13.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 op) Projektiryhmä Jussi Hynninen
LisätiedotARVI-järjestelmän ohje arvioinnin syöttäjälle 13.4. 2015
ARVI-järjestelmän ohje arvioinnin syöttäjälle 13.4. 2015 Sisältö ARVI-menettelyn perusteet... 1 Arvioinnin syöttäminen... 2 Arvion lähettäminen TE-toimistoon... 5 Sovelluksen sulkeminen... 6 Virhetilanteiden
Lisätiedotlineitä oppimisen tueksi
Moodlen välineitv lineitä oppimisen tueksi Ennakkotehtävä Sinulle: 1. Mieti valmiiksi aihe, josta alat laatia verkkokurssia tai kurssin osaa. Verkko tutuksi -kurssilla on tavoitteena suunnitella joko kokonainen
LisätiedotCopyright by Haikala. Ohjelmistotuotannon osa-alueet
Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary
Lisätiedot13/20: Kierrätys kannattaa koodaamisessakin
Ohjelmointi 1 / syksy 2007 13/20: Kierrätys kannattaa koodaamisessakin Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy
LisätiedotLyhyt ohje Ning-verkoston hallinnoimiseksi ja muokkaamiseksi
Lyhyt ohje Ning-verkoston hallinnoimiseksi ja muokkaamiseksi Valtti Valmis tutkinto työelämävalttina, Jenni Kaisto Sisältö NÄKYMÄ SISÄÄNKIRJAUTUESSA... 1 NINGIN HALLINNOINTI JA MUOKKAUS... 3 KOJELAUTA...
LisätiedotSOVELLUSPROJEKTIN ARVIOINTILOMAKE
SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa
LisätiedotConvergence of messaging
Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO
Lisätiedotkertaa samat järjestykseen lukkarissa.
Opetuksen toistuva varaus ryhmällee TY10S11 - Tästä tulee pitkä esimerkki, sillä pyrin nyt melko yksityiskohtaisesti kuvaamaan sen osion mikä syntyy tiedon hakemisesta vuosisuunnittelusta, sen tiedon kirjaamiseen
LisätiedotKUIVAKETJU10:N SÄHKÖISEN JÄRJESTELMÄN KÄYTTÖOHJE
KUIVAKETJU10:N SÄHKÖISEN JÄRJESTELMÄN KÄYTTÖOHJE 27.6.2019 Sisällys 1. Uudet ominaisuudet 8/2019... 3 2. Projektit... 6 2.1. Projektin lisääminen... 6 2.2 Projektin valinta... 7 2.3 Projektin navigointi...
Lisätiedot1. päivä ip Windows 2003 Server ja vista (toteutus)
1. päivä ip Windows 2003 Server ja vista (toteutus) Olette pomosi kanssa tarkastaneet asiakkaan tekemän ja sinun korjaaman suunnitelman ja tehneet oman versionsa siitä. Noudata siis tätä tekemäänne uutta
LisätiedotAnalyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio
Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia
LisätiedotSuvi Junes/Pauliina Munter Tietohallinto/Opetusteknologiapalvelut 2014
Tietokanta Tietokanta on työkalu, jolla opettaja ja opiskelijat voivat julkaista tiedostoja, tekstejä, kuvia ja linkkejä alueella. Opettaja määrittelee lomakkeen muotoon kentät, joiden kautta opiskelijat
LisätiedotOpas administraattori-tason käyttäjille. MANAGERIX -ohjelman esittely... 2 Kirjautuminen... 2
MANAGERIX Opas administraattori-tason käyttäjille SISÄLLYS MANAGERIX -ohjelman esittely... 2 Kirjautuminen... 2 Käyttöliittymä... 2 1 ORGANISAATIO Organisaation tietojen tarkastelu ja muokkaaminen4 Yhteenveto
LisätiedotInternet-pohjainen ryhmätyöympäristö
Menetelmäohje Internet-pohjainen ryhmätyöympäristö Riku Hurmalainen, 24.3.2002 Sisällysluettelo 1. Johdanto...3 2. Termit...4 3. Toteutus...5 3.1. Yleiskuvaus...5 3.2. Tekninen ratkaisu...5 3.3. Tietoturva...6
LisätiedotTikon kassamaksujen käsittely
Lokakuu 2012 1 (14) Käyttöohje Lokakuu 2012 2 (14) Sisällysluettelo Johdanto... 3 1. Turvakoodisarjojen käsittely... 4 1.1. Turvakoodisarjan selausnäyttö... 4 1.2. Turvakoodisarjan ylläpitonäyttö... 4
Lisätiedot582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus
582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus Sisältö Mikä on web-sovellus? Selaimen rooli web-sovelluksessa Palvelimen rooli web-sovelluksessa Aineistopyynnöt Tiedon välittäminen
LisätiedotEsittely. Muistathan, että voit myös käyttää Petsietä aivan normaalina käyttäjänä kasvattajapalveluiden lisäksi. Antoisaa Petsien käyttöä!
Petsie kasvattaja 1 2 Sisällysluettelo Esittely...3 1. Kuinka pääset alkuun...4 1.1. Rekisteröinti...4 2. Lemmikit...4 2.1. Lemmikkien lisäys...4 2.2. Lemmikin tietojen muokkaus...4 3. Kasvattajasivu...5
LisätiedotDiscendum Oy
1 CV+ ansioluettelon luominen ja muokkaus CV+ - Yleistä 3 CV+ -ansioluettelon luominen 5 Tietojen muokkaaminen Perustoiminnot 7 CV+ sisältöjen otsikoiden muokkaus 8 Koulutus- ja työkokemustiedot Todistuksen
Lisätiedot