1.2 Tuote
Toteutamme ohjelmiston, jonka avulla voidaan salata internetin kautta kulkeva pankin ja pankin asiakkaan välinen tietoliikenne. Tuote salaa tietoliikenneyhteyden käyttämällä tunnettuja vahvoja asymmetrisiä ja symmetrisiä salakirjoitusmenetelmiä. Tuote jakaantuu kahteen ohjelmaan, jotka toimivat pankin ja pankin asiakkaan sisäisissä verkoissa. Tästä eteenpäin pankin verkossa toimivaa ohjelmaa kutsutaan pankin proxyksi ja pankin asiakkaan verkossa toimivaa ohjelmaa asiakkaan proxyksi.
Tietoliikenne salataan ohjaamalla pankin asiakkaan ja pankin välinen TCP/IP-liikenne kulkemaan asiakkaan proxyn ja pankin proxyn välisen turvallisen salakirjoitetun yhteyden läpi. Asiakkaan toiveena on lisäksi liikenteen kiistämättömyys, ts. pankki voi osoittaa liikenteen (tapahtumien) tulleen asiakkaan valtuuttamalta taholta. Vastaavasti pankin asiakas voi varmistua, että salattua proxy-käytävää pitkin saapuneet tiedot ovat pankin lähettämiä.
On huomattava, että ohjelmiston tarkoituksena on vain luoda turvallinen yhteyskäytävä
pankin ja pankin asiakkaan verkkojen välille. Pankin ja pankin asiakkaan tehtäväksi jää
organisaation sisäisen verkon turvallisuuden varmistaminen esimerkiksi palomuurilla, jonka
läpi proxyt liikennöivät.
Projektin dokumenteissä kuten suunnitelmissa, määritelmissä, raporteissa jne. käytetty
terminologia on koostettu erilliseen listaan lyhyine selityksineen.
Teksteissä esiintyvät viittaukset ja käytetty
lähdemateriaali on listattu erillisessä lähdeluettelossa.
Järjestelmä koostuu proxy-ohjelmasta, joka voidaan konfiguroida kahdella tavalla:
asiakkaan proxy pankin asiakkaalle ja pankin proxy pankille. Ohjelmien versiot
tulevat olemaan suurimmaksi osaksi identtiset; pankin proxy on kuitenkin
enemmän palvelin-tyyppinen kuin asiakkaan proxy. Seuraavassa kuvataan
yleisellä tasolla ohjelmistolta halutut ominaisuudet.
Proxy-käytävän yli kulkeva liikenne allekirjoitetaan lähettävän osapuolen
salaisella avaimella, jolloin vastaanottava proxy voi tarkistaa saapuneen sanoman
tulleen todellakin yhteyden alussa tunnistetulta lähettäjältä.
Proxy-ohjelmat toimivat itsenäisesti käyttöjärjestelmien puitteissa.
Kurssin puitteissa toteutettavan demo-ohjelman toteutusympäristö on Linux.
Ohjelmiston kääntäminen myös muihin ympäristöihin (kuten Win95/98/NT)
on mahdollista kohtuullisella vaivalla, koska ohjelmisto toteutetaan
helposti siirrettäviksi ja vältetään käyttöjärjestelmäriippuvien rajapintojen käyttöä.
Ohjelmiston käyttöliittymä on komentorivipohjainen. Avain- ja
lokitiedostot ovat tekstimuotoisia, käyttöliittymä komentorivipohjainen.
Seuraavassa on listattu ohjelmiston toiminnot priorisoituna asiakkaan tarpeen mukaisesti.
Välttämättömiksi toiminnoiksi on luokiteltu toiminnot, jotka ovat välttämättömiä
ohjelman turvallisen toiminnan kannalta tai projekti ei ole
täyttänyt asiakkaan sille asetettamia vaatimuksia.
Välttämättömiksi toiminnoiksi on luokiteltu seuraavat toiminnot
Tarpeellisia toimintoja ovat toiminnot, jotka eivät ole välttämättömiä ohjelman
toiminnan kannalta, mutta ovat kuitenkin oleellisia ohjelman tehokkaan käytön kannalta.
Tarpeellisiksi toiminnoiksi on katsottu
Lisäominaisuuksiksi on laskettu ne toiminnot, joiden toteuttaminen on rajattu
projektin ulkopuolelle. Ne otetaan kuitenkin huomioon projektin aikana siten, että ne olisi
tarvittaessa helposti lisättävissä tuotteeseen.
Seuraavassa on dokumentoitu ohjelman tärkeimmät riippuvuudet eri rajapinnoista ja käyttöjärjestelmän
palveluista.
Proxy-ohjelmat kommunikoivat asiakkaan maksuliikenneohjelmiston ja pankin
maksuliikennepalvelun kanssa TCP/IP-protokollan välityksellä. Proxyjen väliseen
liikenteeseen käytetään myös TCP/IP-protokollaa, jonka välittämänä salattu liikenne
kulkee proxystä toiseen.
Proxya käynnistettäessä tarvitaan tieto kuunneltavista TCP-porteista ja sekä tieto mihin porttiin
tuleva yhteydenotto ohjataan eteenpäin pankin järjestelmässä. Demo-ohjelmassa tiedot annetaan komentoriviltä.
Yhteyttä muodostettaessa yhteyttä ottavan proxyn tulee ennalta tietää vastapään proxyn julkinen
avain, jotta yhteys voidaan muodostaa turvallisesti. Ohjelma ei saa kadottaa
julkisia avaimia jos se esimerkiksi joudutaan käynnistämään uudelleen. Tämän vuoksi julkiset
avaimet tallennetaan ns. avainrenkaaseen, joka on tekstitiedosto. Avainrenkaan toteutus
on hyvin vaatimaton kurssin puitteissa toteutettavassa demo-ohjelmistossa, mutta dokumentaatiossa
esitetään kehittyneempiä ratkaisuja jatkokehitystä silmällä pitäen.
Yhteyden salaus ja autentikointi toteutetaan tunnettuilla vahvoilla
salausmenetelmillä (esim. RSA asymmetriseen salakirjoitukseen, 3DES symmetriseen
salakirjoitukseen ja SHA-koosteiden tuottamiseen). Tarkoituksena on käyttää yleisesti
tunnettuja ja hyväksi havaittuja menetelmiä, jotta myös ohjelmistolla on edellytykset nauttia yleistä
luottamusta.
Ohjelmisto toipuu tietoliikenneyhteyden virhetilanteista. Asetustiedostojen puutteellisuudesta
tai muista virhetilanteista toivutaan mahdollisuuksien mukaan.
Ohjelmisto kykenee välittämään useampia yhteyksiä samanaikaisesti ilman
että yhteydet häiritsevät toisiaan muussa mielessä kuin koneen kuormituksen kasvamisena.
Demo-ohjelma luovutetaan havainnollistamaan toiminnallisuutta, mutta projektiryhmä
ei sitoudu jatkokehittämään tuotetta.
Ei toteuteta kurssin puitteissa.
Ryhmä ja asiakas ovat yhteistyössä laatineet laatukriteerit, joiden avulla voidaan projektin aikana sekä lopuksi arvioida projektin onnistumista. Laatukriteerit on listattu tärkeysjärjestyksessä. Eri kriteerien merkityksessä painaa eniten asiakkaan näkökulma, ja tärkeintä on päästä pyrittyyn tavotteeseen.
Tavoitteeseen pyritään ensisijaisesti tiiviillä yhteistyöllä ryhmän ja asiakkaan välillä.
Erityisesti projektin määrittely- ja suunnitteluvaiheissa asiakkaan tarpeen ja projektin tavoitteiden
tarkka kartoittaminen on tärkeää. Ryhmän täytyy perehtyä aiheeseen huolellisesti (mm.
maksuliikenneohjelmien yhteyskäytäntöjen selvittäminen), jotta vältytään yllätyksiltä projektin
loppuvaiheessa.
Tuotteen toimivuudesta pidetään huolta projektin aikana
Tärkein yksittäinen mittari asiakastyytyväisyydelle projektin aikana on asiakkaan eri projektin
vaiheille antama arvostelu. Projektin päättyessä asiakastyytyväisyyden mittarina toimivat mahdollinen
jatkoprojekti ja ohjelmiston käyttöönotto.
Jokaisessa projektin vaiheessa (erityisesti protot) arvioidaan seuraavaan vaiheeseen kuluva aika.
Projektin uudessa vaiheessa opitaan edellisen vaiheen aikataulun arvioinnissa mahdollisesti tehdyistä
virheistä ja ennen kaikkea pyritään olemassaolevien tuntilistojen ja työkirjanpidon avulla selvittämään
mihin arvioitu aika kului, tai jäikö sitä yli ja miksi.
Onnistumisen arviointi
Verrataan aikaisemmin tehtyä arviota todellisiin lukuihin. Kurssin aikarajojen saavuttaminen.
Projektin WWW-sivujen reaaliaikainen päivittäminen. Tiivis yhteydenpito myös puhelimitse ja
sähköpostitse asiakkaaseen. Riittävän usein perusteelliset palaverit.
Onnistumisen arviointi
Asiakkaalta ja kurssilta saatu palaute.
Dokumentaatio on osa asiakkaan tuotteesta, joten sitä koskee samat vaatimukset kuin itse
ohjelmistoa.
Toimenpiteet tavoitteen saavuttamiseksi
Dokumentteja kirjoitetaan pitkällä aikajänteellä ja materiaalin tulee olla valmis ajoissa ennen
palautuspäivämääriä. Kaiken materiaalin lukee vähintään kaksi ryhmän jäsentä läpi ja, erityisesti
tuotemääritelmien osalta, myös asiakas käy materiaalin läpi.
Onnistumisen arviointi
Eri dokumentteja kirjoitetaan eri lukijoille. Laatu on hoidettu hyvin, jos lukijat ymmärtävät
keskeisen sisällön ja jos dokumentin sisältö kattaa dokumentoitavan aiheen. Onnistuneita dokumentteja
ei tarvitse muutella ajan myötä yhtä paljon kuin puutteellisia tai virheellisiä.
Mahdollista jatkoprojektia varten ohjelman koodin on oltava helposti muutettavissa ja uusia
ominaisuuksia tulee olla mahdollista lisätä.
Ideaalitilanteessa ohjelmiston suunnitteluvaiheessa kyetään luomaan ohjelman selkeä jaottelu
riippumattomiin osiin, jotka voidaan toteuttaa ja testata erikseen; ohjelmistotuotanto on kuitenkin
valitettavan usein iteratiivinen prosessi ja on varauduttava, sekä aikataulussa että henkisesti, että matkassa voi olla mutkia.
Toimenpiteet tavoitteen saavuttamiseksi
Tavoitteeseen pyritään
Onnistumisen arviointi
Ryhmä arvioi itse ja antaa toisilleen palautetta tehdyn koodin laadusta. Tuotettu koodi ei saa olla
myöskään "musta laatikko" asiakkaalle vaan oleellisia osia tullaan esittelemään mm. pankin tekniselle
osastolle.
Jo vaatimusmäärittelyvaiheessa voidaan eritellä seuraavat riippumattomat abstraktit ohjelman osat, joita
voidaan käyttää sellaisenaan myös projektin ulkopuolella, ja joiden toteutukset tulee piilottaa ohjelman
muilta osilta mahdollisimman tehokkaasti.
Luokat, rajapinnat ja luokan sisäiset toiminnot dokumentoidaan käyttämällä automaattista dokumentointityökalua,
joka luo lähdekoodin kommenttien avulla HTML-dokumentin ohjelman lähdekoodista.
Onnistumisen arviointi
"Autodoc"-työkalun käyttö takaa dokumentaation kattavuuden, mikäli sitä käytetään kaikkien lähdekooditiedostojen dokumentointiin.
Koodaaja/tarkastaja -malli. Koodaaja luovuttaa mielestään toimivan, dokumentoidun lähdekoodin pätkän tarkastajalle,
jonka tehtävänä on tutustua siihen. Ohjelman tarkastajan on ymmärrettävä mitä ohjelmanpätkä (ainakin periaatteellisesti)
tekee lukemalla lähdekooditiedosto läpi -- mikäli tässä ei onnistuta, on dokumentoinnissa vikaa.
Menetelmän hyötynä saavutetaan lisäksi
Onnistumisen arviointi
Koodaaja/tarkastaja -malli. Tarkastaja kommentoi objektiivisesti koodaajan tekemää koodia ja tekee tarvittavat korjausehdotukset
ja selvityspyynnöt. Asiakkaan edustaja (esim. pankin tekninen osasto) tutustuu dokumentointiin.
1.3 Käytetyt termit ja lähteet
2. Yleiskuvaus
2.1 Ohjelman yleiset toiminnalliset vaatimukset
Pankin asiakkaan ja pankin välinen TCP/IP-yhteys salataan ohjaamalla
pankin asiakkaan maksuliikenneohjelman TCP/IP-liikenne pankin asiakkaan
(suojatussa) verkossa olevaan asiakkaan proxyyn. Asiakkaan proxy muodostaa salatun
yhteyden (mahdollisesti turvattoman) verkon läpi pankin proxyyn, joka on
pankin (suojatussa) verkossa. Pankin proxy ottaa edelleen yhteyden pankin
maksuliikennepalveluun (kts. oheinen kuva). Muodostetun turvallisen
TCP/IP yhteyden läpi
asiakkaan on mahdollista välittää maksuliikenneohjelmiston avulla toimeksiantoja
pankkiin ja saada tietoja pankista.
2.2 Ohjelman toimintaympäristö
2.3 Käyttöliittymä
3. Toiminnot
3.1 Välttämättömät toiminnot
3.2 Tarpeelliset toiminnot
3.3 Lisäominaisuudet
4. Ulkoiset liittymät
4.1. Tietoliikenne
4.2. Asetustiedostot
4.3. Avainten tallentaminen
5. Muut ominaisuudet
5.1 Turvallisuus
5.2 Luotettavuus
5.3 Suorituskyky
5.4 Ylläpidettävyys
5.5 Siirrettävyys
6. Laatusuunnitelma
6.1 Tuottaa asiakkaan toiveet täyttävä toimiva ohjelmisto
Toimenpiteet tavoitteen saavuttamiseksi
Onnistumisen arviointi
6.2 Aikataulussa pysyminen
Toimenpiteet tavoitteen saavuttamiseksi
6.3 Asiakkaan (ja kurssin henkilökunnan) pitäminen ajantasalla projektin etenemisestä
Toimenpiteet tavoitteen saavuttamiseksi
6.4 Projektin kattava ja selkeä dokumentointi
6.5 Ohjelman modulaarisuus, koodin uudelleenkäytettävyys
Projektin jokaisessa vaiheessa voidaan tarkastella eri ohjelman osien keskinäistä riippumattomuutta ja
tehdyn koodin laatua; edellämainittu abstraktien osien lista tulee todennäköisesti tarkentumaan projektin
edetessä. Konkreettisina laatumittareina voidaan käyttää ohjemiston hierarkisuutta ja koodin määrää.
6.6 Ohjelman kattava dokumentointi
Toimenpiteet tavoitteen saavuttamiseksi
6.7 Ohjelman selkeä dokumentointi
Toimenpiteet tavoitteen saavuttamiseksi