Page History

...

Tarkastettavaa:

• vetuma-speksista tietuekuvauksia
• siirron tilakoodit, että vastaa tarvittavia siirtotiloja

4.2.5.7 AssignmentRow-taulu: Toimeksiantorivi-taulu

Toimeksiannot sisältävät useamman rivin, jotta yhdellä toimeksiannolla voidaan käsitellä useampaa kuin vain yhtä tuotetta kerrallaan (esim. avoimen opintojakso toteutuksia). Tietojen tulee olla aina tosiaikaista tilannetta vastaavia siihen saakka kunnes toimeksianto siirtyy maksuvaiheeseen, jolloin rivien tilanne jäädytetään, eli rivejä ei voi enää lisätä, poistaa tai muuttaa.

Avoimet kysymykset:

• Intime projektitunnuksen käyttö

4.2.5.8 Basket-taulu: Poimintakori-taulu

Poimintakoriin kerätään käyttäjän tekemät poiminnat ennen maksutapahtumaa. Kun käyttäjä on valmis siirtymään varsnaiseen ostostapahtumaan, siirretään tiedot toimeksiantoon käsiteltäväksi. Poimintakori voi sisältää usemman kuin yhden rivin.

Joissakin asiontitapauksissa ei ole pakko käyttää poimintakoria, kuten käsittelymaksun suorittamisessa.

4.2.5.9 BasketRow-taulu: Poimintakoririvi-taulu

Poimintakorin rivit tallennetaan tähän tauluun.

4.2.5.10 IntimeProduct-taulu: IntimePlus-järjestelmästä replikoidut tuotteet

IntimePlus järjestelmästä replikoitua tietoa.

Avoimet kysymykset:

• intimeplussan tietotyypit ja tietuepituudet

4.2.5.11 IntimeProject-taulu: IntimePlus-järjestelmästä replikoidut projektit

IntimePlus järjestelmästä replikoitua tietoa.

Avoimet kysymykset:

• intimeplussan tietotyypit ja tietuepituudet

4.2.5.12 IntimeEducationProgram-taulu: IntimePlus-järjestelmästä replikoidut koulutusohjelmat

IntimePlus järjestelmästä replikoitua tietoa.

Avoimet kysymykset:

• intimeplussan tietotyypit ja tietuepituudet

Pohja

• tarkat kuvaukset per taulu kenttätasolla!
• tsekkaa kenttänimet vastaamaan ensisijaisesti metropolia nimiä ja sitten xdw-mallia vasten, tarvittaessa käytä aliaksia!
• tietokantamallia päivitetään kun määrittelydokumentti täydentyy

Tietokannan eri taulujen väliset relaatiot on kuvattu seuraavassa kaaviossa:

...

Tietokanta - taulut

...

Image Removed

Puuttuvat kentät:

Määriteltävää:

• opiskelijan lajittelutekijät hakukäyttöliittymissä: koulutusohjelma (kysytään kun opiskelija suorittaa maksua) / kustannuspaikka / projekti

4.2.6 Tekniset vaatimukset

• ympäristöjen tekniset vaatimukset (edes jotain) palvelin, että toiminnallisuus näkökulmasta
• "palvelimien tulee olla teknisesti suojattu... palveluita käytetään vain ssl-rajapintojen kautta"
• huomautetaan, että määrittelyjä voidaan tarkentaa...

4.2.7 OPI-Maksut projektin vaatimuksien huomioon ottaminen

• something, something, the dark side

5. Toteutussuunnitelma

Järjestelmän toteutus tehdään normaalien kehitysmenetelmien avulla. Kehityssykliin kuuluu siis määrittely, toteutus, testaus ja käyttöönotto.

Kehittäjille tulee tarjota tarvittavat tiedot määrittelyissä teknisen toteutuksen rakentamiseen. Metropolian ulkopuolisten teknisten rajapintojen määrittelyiden ensisijainen lähde on ao. rajapintojen tekniset dokumetaatiot.

Kehittäjien kohdatessa prosesseihin liittyviä sisällöllisiä ongelmia, tulee ongelmat ratkoa projektipäällikön avustuksella.

Toteutusvaiheessa olennaista on tarvittavien testausmenettelyjen noudattaminen. Lisäksi loppukäyttäjät tulee sitoa mukaan testaukseen mahdollisimman aikaisessa vaiheessa ennen käyttöönottoa.

6. Testaussuunnitelma

Projektin kuluessa tulee noudattaa hyväksi todettuja testausmenettelyjä. Testausmenettelyjä tulee soveltaa niin määrittelyihin kuin varsinaisiin ohjelmistototeutuksiin.

Periaatteet ovat seuraavat:

• Testataan toiminnallisuudet käyttämällä toimintojen käyttäjätarinoita viitekehyksenä.
• Testataan toiminnallisuudet joko käytettävyyden näkökulmasta tai rajapintojen kohdalta teknisiä rajapintakuvaksia vasten.
• Testaajien tulee parhaansa mukaan yrittää löytää poikkeavia toimintatapoja, joihin ei määrittelyssä ole voitu ennakoida
• Jokaisesta virhetilanteesta tulee tehdä virheraportti

Järjestelmän tietoturvallisuus tulee käydä läpi tarvittaessa penetraatiotestauksella.

Lisäksi eri vaiheissa sovelletaan seuraavia periaatteita:

6.1 Määrittelyt ja käyttöliittymäprotot

Määrittelyjen pohjalla olevien prosessien prosessikuvaukset tulee olla hyväksytettyjä ao. prosessit omistavissa Metropolian yksiköissä.

Määrittelyt tulee käydä läpi vähintään vertaistarkistuksen kautta. Tavoitteena on, että koko Metropolian kehitystiimi on käynyt läpi määrittelyt vähintään omalta osaltaan. Lisäksi eri osioiden määrittelydokumentit tulee käydä osiot toteuttavien kehittäjien kautta.

Määrittelyissä mukana olevat käyttölittymäprotot tulee olla tarkastettu Metropolian käyttöliittymä asiantuntijoilla, mikäli niitä ei ole tehty heidän toimestaan.

6.2 Kehitysvaihe: palveluväylä

Palveluväylän toimintojen ja liittymärajapintojen testaus tehdään aina teknisissä määrittelyissä olevia teknisiä kuvauksia vasten, eli rajapintojen muodostamat tiedot tulee vastata määrittelyjä. Vähin hyväksyttävä taso on täsmällinen määrittelyjen vastaavuus.

Mikäli kolmannen osapuolen rajapinnoissa pystyy käyttämään esim. xml-tiedoston validointia, tulee näitä tekniikoita käyttää.

Sovelluskehityksessä tulee käyttää mahdollisuuksien mukaan yksikkötestausta, mutta tämä ei ole vähimmäistaso, jolla testaus voidaan katsoa suoritetuksi.

6.3 Kehitysvaihe: asiointisovellus

Asiointisovelluksen testaus koostuu kahdesta osasta: ohjelmistotestaus ja käytettävyystestaus.

Ohjelmistotestauksessa sovelletaan samoja periaatteita kuin palveluväylän testauksessa.

Näiden periaatteiden lisäksi tulee asiointisovelluksen osalta tehdä myös mahdollisuuksien käytettävyystestaus. Vähimmäistasolla asiointisovelluksen käyttöliittymä tulee käydä läpi toteuttajan ja käytettävyyssuunnittelijan kanssa ja sopivalla vertaiskäyttäjä testauksella.

Lisäksi, koska asiointisovellus on selainkäyttöinen sovellus, tulee asiointisovelluksen toiminnallisuus varmistaa yleisimmillä käytössä olevilla selainohjelmistoilla Windows 7 ja Mac-alustoilla.

6.4 Käyttöottovaiheen testaukset

Käyttöönottovaiheessa tehtävien ongelmien korjaamiseksi tehtävä korjaukset voidaan viedä tuotantoon nopeammalla testaussyklillä, mutta vähimmäistason testauksesta ei saa tinkiä. Yhtään testaamatonta komponenttia ei saa viedä käyttöönottovaiheessa olevaan järjestelmään.

6.5 Ylläpitovaiheen testaukset

Samat testausperiaatteet kuin kehitys- ja ylläpitovaiheessa pätevät myös ylläpitovaiheessa. Olennaista on hallitun testausmenettelyn ylläpitämiseksi on rakentaa ylläpito vaiheen ajaksi malli, jossa on olemassa järjestelmästä seuraavat ympäristöt:

• kehitysympäristö: uudet ominaisuudet ja kehittäjätestaus tapahtuvat tässä ympäristössä. Kehitysympäristöt voivat sijaita kehittäjien omilla tietokoneilla, kunhan ohjelmistokoodien hallinnassa käytetään versionhallintaympäristöä.
• hyväksymistestausympäristö: ennen tuotantoon siirtoa loppukäyttäjät testaavat uudet ominaisuudet ja korjaukset tässä ympäristössä. Ympäristö vastaa mahdollisimman hyvin tietosisällöltään tuotantoympäristöä.
• tuotantoympäristö: tässä ympäristössä tapahtuu tuotantokäyttö. Tuotantoympäristössä ei testata.

7. Käyttöönottosuunnitelma

Järjestelmän ensi julkaisu tuotantoon tehdään vasta, kun järjestelmän Metropolian sisäinen tilaaja on hyväksynyt järjestelmän hyväksymistestausympäristössä.

Järjestelmän käyttöönotto suoritetaan aina siten, että uudet ominaisuudet ja korjaukset hyväksytetään testauksesta vastaavilla henkilöillä ennen ominaisuuksien siirtoa tuotantojärjestelmään.

8. Ylläpitosuunnitelma

Järjestelmän ylläpidossa tulee huolehtia seuraavista asioista:

• varmistukset: järjestelmän tuottamista tiedoista pitää ottaa säännöllisesti varmistukset. Tietokannoista pitää tämän vuoksi ottaa päivitykset mieluiten päivittäin (koko tietokanta).
• palvelutaso: järjestelmän asiointisovelluksen käytön pitää olla lähes katkeamatonta. Järjestelmä saa olla pois käytöstä suunniteltuina käyttökatkosaikoina, jolloin käyttäjälle ilmoitetaan palvelun etusivulla käyttökatkosta (nk. huoltotila).
• skaalautuvuus: kun järjestelmään lisätään avoimen ammattikorkeakoulun toiminnot, tulee käytössä olemaan selviä korkeamman käytön jaksoja. Näihin tulee varautua.
• muutoksen hallinta: järjestelmään ei lisätä uusia ominaisuuksia ilman suunnitelmallista toimintaa. Järjestelmän omistajalla Metropoliassa on velvollisuus ja vastuu koordinoida järjestelmässä tapahtuvia muutoksia.

Tyhjäpohja: Prosessikuvaus

...

Vaiheen nro

...

Mitä tapahtuu?

...

Kuka tekee?

...

Millä tavalla?

...

Mikä on lopputulos?

Tietokannan eri taulujen väliset relaatiot on kuvattu seuraavassa kaaviossa:

...

Tietokanta - taulut

...

Image Added

Puuttuvat kentät:

Määriteltävää:

• opiskelijan lajittelutekijät hakukäyttöliittymissä: koulutusohjelma (kysytään kun opiskelija suorittaa maksua) / kustannuspaikka / projekti

4.2.6 Tekniset vaatimukset

• ympäristöjen tekniset vaatimukset (edes jotain) palvelin, että toiminnallisuus näkökulmasta
• "palvelimien tulee olla teknisesti suojattu... palveluita käytetään vain ssl-rajapintojen kautta"
• huomautetaan, että määrittelyjä voidaan tarkentaa...

4.2.7 OPI-Maksut projektin vaatimuksien huomioon ottaminen

• something, something, the dark side

5. Toteutussuunnitelma

Järjestelmän toteutus tehdään normaalien kehitysmenetelmien avulla. Kehityssykliin kuuluu siis määrittely, toteutus, testaus ja käyttöönotto.

Kehittäjille tulee tarjota tarvittavat tiedot määrittelyissä teknisen toteutuksen rakentamiseen. Metropolian ulkopuolisten teknisten rajapintojen määrittelyiden ensisijainen lähde on ao. rajapintojen tekniset dokumetaatiot.

Kehittäjien kohdatessa prosesseihin liittyviä sisällöllisiä ongelmia, tulee ongelmat ratkoa projektipäällikön avustuksella.

Toteutusvaiheessa olennaista on tarvittavien testausmenettelyjen noudattaminen. Lisäksi loppukäyttäjät tulee sitoa mukaan testaukseen mahdollisimman aikaisessa vaiheessa ennen käyttöönottoa.

6. Testaussuunnitelma

Projektin kuluessa tulee noudattaa hyväksi todettuja testausmenettelyjä. Testausmenettelyjä tulee soveltaa niin määrittelyihin kuin varsinaisiin ohjelmistototeutuksiin.

Periaatteet ovat seuraavat:

• Testataan toiminnallisuudet käyttämällä toimintojen käyttäjätarinoita viitekehyksenä.
• Testataan toiminnallisuudet joko käytettävyyden näkökulmasta tai rajapintojen kohdalta teknisiä rajapintakuvaksia vasten.
• Testaajien tulee parhaansa mukaan yrittää löytää poikkeavia toimintatapoja, joihin ei määrittelyssä ole voitu ennakoida
• Jokaisesta virhetilanteesta tulee tehdä virheraportti

Järjestelmän tietoturvallisuus tulee käydä läpi tarvittaessa penetraatiotestauksella.

Lisäksi eri vaiheissa sovelletaan seuraavia periaatteita:

6.1 Määrittelyt ja käyttöliittymäprotot

Määrittelyjen pohjalla olevien prosessien prosessikuvaukset tulee olla hyväksytettyjä ao. prosessit omistavissa Metropolian yksiköissä.

Määrittelyt tulee käydä läpi vähintään vertaistarkistuksen kautta. Tavoitteena on, että koko Metropolian kehitystiimi on käynyt läpi määrittelyt vähintään omalta osaltaan. Lisäksi eri osioiden määrittelydokumentit tulee käydä osiot toteuttavien kehittäjien kautta.

Määrittelyissä mukana olevat käyttölittymäprotot tulee olla tarkastettu Metropolian käyttöliittymä asiantuntijoilla, mikäli niitä ei ole tehty heidän toimestaan.

6.2 Kehitysvaihe: palveluväylä

Palveluväylän toimintojen ja liittymärajapintojen testaus tehdään aina teknisissä määrittelyissä olevia teknisiä kuvauksia vasten, eli rajapintojen muodostamat tiedot tulee vastata määrittelyjä. Vähin hyväksyttävä taso on täsmällinen määrittelyjen vastaavuus.

Mikäli kolmannen osapuolen rajapinnoissa pystyy käyttämään esim. xml-tiedoston validointia, tulee näitä tekniikoita käyttää.

Sovelluskehityksessä tulee käyttää mahdollisuuksien mukaan yksikkötestausta, mutta tämä ei ole vähimmäistaso, jolla testaus voidaan katsoa suoritetuksi.

6.3 Kehitysvaihe: asiointisovellus

Asiointisovelluksen testaus koostuu kahdesta osasta: ohjelmistotestaus ja käytettävyystestaus.

Ohjelmistotestauksessa sovelletaan samoja periaatteita kuin palveluväylän testauksessa.

Näiden periaatteiden lisäksi tulee asiointisovelluksen osalta tehdä myös mahdollisuuksien käytettävyystestaus. Vähimmäistasolla asiointisovelluksen käyttöliittymä tulee käydä läpi toteuttajan ja käytettävyyssuunnittelijan kanssa ja sopivalla vertaiskäyttäjä testauksella.

Lisäksi, koska asiointisovellus on selainkäyttöinen sovellus, tulee asiointisovelluksen toiminnallisuus varmistaa yleisimmillä käytössä olevilla selainohjelmistoilla Windows 7 ja Mac-alustoilla.

6.4 Käyttöottovaiheen testaukset

Käyttöönottovaiheessa tehtävien ongelmien korjaamiseksi tehtävä korjaukset voidaan viedä tuotantoon nopeammalla testaussyklillä, mutta vähimmäistason testauksesta ei saa tinkiä. Yhtään testaamatonta komponenttia ei saa viedä käyttöönottovaiheessa olevaan järjestelmään.

6.5 Ylläpitovaiheen testaukset

Samat testausperiaatteet kuin kehitys- ja ylläpitovaiheessa pätevät myös ylläpitovaiheessa. Olennaista on hallitun testausmenettelyn ylläpitämiseksi on rakentaa ylläpito vaiheen ajaksi malli, jossa on olemassa järjestelmästä seuraavat ympäristöt:

• kehitysympäristö: uudet ominaisuudet ja kehittäjätestaus tapahtuvat tässä ympäristössä. Kehitysympäristöt voivat sijaita kehittäjien omilla tietokoneilla, kunhan ohjelmistokoodien hallinnassa käytetään versionhallintaympäristöä.
• hyväksymistestausympäristö: ennen tuotantoon siirtoa loppukäyttäjät testaavat uudet ominaisuudet ja korjaukset tässä ympäristössä. Ympäristö vastaa mahdollisimman hyvin tietosisällöltään tuotantoympäristöä.
• tuotantoympäristö: tässä ympäristössä tapahtuu tuotantokäyttö. Tuotantoympäristössä ei testata.

7. Käyttöönottosuunnitelma

Järjestelmän ensi julkaisu tuotantoon tehdään vasta, kun järjestelmän Metropolian sisäinen tilaaja on hyväksynyt järjestelmän hyväksymistestausympäristössä.

Järjestelmän käyttöönotto suoritetaan aina siten, että uudet ominaisuudet ja korjaukset hyväksytetään testauksesta vastaavilla henkilöillä ennen ominaisuuksien siirtoa tuotantojärjestelmään.

8. Ylläpitosuunnitelma

Järjestelmän ylläpidossa tulee huolehtia seuraavista asioista:

• varmistukset: järjestelmän tuottamista tiedoista pitää ottaa säännöllisesti varmistukset. Tietokannoista pitää tämän vuoksi ottaa päivitykset mieluiten päivittäin (koko tietokanta).
• palvelutaso: järjestelmän asiointisovelluksen käytön pitää olla lähes katkeamatonta. Järjestelmä saa olla pois käytöstä suunniteltuina käyttökatkosaikoina, jolloin käyttäjälle ilmoitetaan palvelun etusivulla käyttökatkosta (nk. huoltotila).
• skaalautuvuus: kun järjestelmään lisätään avoimen ammattikorkeakoulun toiminnot, tulee käytössä olemaan selviä korkeamman käytön jaksoja. Näihin tulee varautua.
• muutoksen hallinta: järjestelmään ei lisätä uusia ominaisuuksia ilman suunnitelmallista toimintaa. Järjestelmän omistajalla Metropoliassa on velvollisuus ja vastuu koordinoida järjestelmässä tapahtuvia muutoksia.

...

Tyhjäpohja: Prosessikuvaus

Tyhjäpohja: Käyttötapaus

...

Tietokantataulu pohja

...

1.

Tyhjäpohja: Käyttötapaus

...

Yleiskuvaus

...

Laatija

...

Päiväys

...

Prosessi

...

Käyttäjärooli

...

Kuvaus

...

Oikeudet

...

Käyttötiheys

...

...

...

...

...

Esitiedot/Ehdot