[ yleistä ] [ julkaisut ] [ yhteystiedot ] [ pohjat ] [ palautukset ] MobSSH
MobSSH
Projektisuunnitelma http://www.niksula.cs.hut.fi:80/~mkomu/mobssh/julkaisut/projektisuunnitelma.html
1.0 Kurssille palautettava dokumentti
Saari Tuomo Viimeksi muokattu: 17.10.2000
Versiohistoria
0.9 12.10.2000 Saari Tuomo Lisätty resurssiarviot ja asiakkaan kuvaus ja tehty muita pieniä korjauksia
0.91 15.10.2000 Saari Tuomo Katselmointi tehty ja muutamia korjauksia tekstiin
Tarkastanut Hyväksynyt
16.10.2000 Jukka Ahonen 16.10.2000 Mika Kousa

Lyhyt tiivistelmä

MobSSH on Teknillisen Korkeakoulun kurssille Tik-76.115 toteutettava opinnäytetyö. Sen tarkoituksena on tarkastella SSH1 protokollan käyttömahdollisuuksia EPOC-ympäristössä ja kerätä kokemuksia tulevaisuutta varten. Projektin tuotteena on tarkoitus tuottaa SSH1 standardin mukainen implementaatio protokollasta valikoiduin osin.

Projektin asiakkaana on Open Information Oy, joka tutkii ja kehittää langattoman tietoliikenteen ratkaisuja. Projekti on osana laajempaa tutkimushanketta, jonka tarkoitus on tutkia ns. wireless life asioita, eli miten erilaisia palveluita voitaisiin tarjota langattomassa tietoliikenneyhteiskunnassa.

Projektiryhmään kuuluu Tuomo Saari, Tero Nordström, Mika Kousa, Antti Järvinen, Jukka Ahonen, Kristian Slavov ja Miika Komu. Asiakkaan edustaja ja projektiryhmän ohjaaja on Arto Sinkkonen.

Projektin onnistumisen ja lopputuotteen laadun takamiseksi projektilla on erillinen laatukäsikirja, joka kattaa sekä hallinnolliset prosessit että itse tuotteen tekemiseen liittyvät toimintatavat ja työkalut. Projektilla on myös erillinen riskienhallintasuunnitelma, jonka avulla projektin riskit pyritään hallitsemaan.

Sisällysluettelo

  1. Johdanto
  2. Termit ja määritelmät
  3. Projektin organisaatio
  4. Projektin tavoitteet ja päättäminen
  5. Projektin resurssit
  6. Projektissa käytettävät menetelmät ja työkalut
  7. Projektin ositus, vaiheistus ja resurssointi
  8. Seuranta ja ohjaus
  9. Standardit, direktiivit ja määräykset
  10. Riskienhallintasuunnitelma
  11. Hylätyt ratkaisuvaihtoehdot

1. Johdanto

Tässä kappaleessa esitellään MobSSH-ohjelmistoprojekti yleisesti, projektin sidosryhmät ja tekijänoikeuksiin liittyvät kysymykset. Kappaleen lopussa esitellään tämän dokumentin loppuosan rakenne.

1.1 Käsitteistöä

Tässä kappaleessa esitellään raportin lukemisen kannalta keskeisimmät käsitteet. Tekniseen ja muuhun yksityiskohtaiseen käsitteistöön palataan seuraavassa kappaleessa.

1.2 Projektin tavoitteet ja rajaus.

MobSSH ohjelmistoprojekti toteutetaan Teknillisen Korkeakoulun tietotekniikan osaston Tik-76.115 Ohjelmatyö-kurssin opiskelijatyönä. Projektin tarkoituksena on tutkia SSH1 protokollan mahdollisuuksia EPOC ympäristössä ja tuottaa tutkimuskäyttöön soveltuva implementaatio tarvittavine osineen. Projekti ei kata SSH1 protokollan kaikkia osia, vaan SSH1 standardin mukaisesta implementaatiosta toteutetaan vain soveltuvat osat.

Asiakkaan kannalta projektin onnistuminen avaa uusia mahdollisuuksia EPOC-pohjaisten laitteiden tietoturvan kehittämisessä ja auttaa asiakasta eteenpäin tutkimus- ja kehitystyössä. Alustavan tutkimuksen perusteella ei löytynyt yhtään varsinaista implementaatiota SSH1 protokollasta EPOC käyttöjärjestelmään, joten projektin uutuusarvo asiakkaalle on selkeä.

Tarkempi kuvaus projektin lopputuotteesta ja teknisistä vaatimuksista esitetään osiltaan tässä dokumentissä ja tarkemmin vaatimusmäärittely dokumentissa.

1.3 Projektin asiakas

Projektin asiakas on Open Information Oy. Open Information Oy on kehittynyt kapea-alaisesta tietokoneohjelmistojen ja tietoliikenneprotokollien alihankinnasta asiakaslähtöiseksi langattoman tietoliikenteen ja ajanhallintasovellusten asiantuntijaksi. Open Information Oy:n tuotteisiin kuuluu iDEALTIME - kalenterisovellus, joka on kelpuutettu Nokian Communicator langattomaan viestimeen. Open Information Oy pyrkii tuottamaan lisäarvoa mobiililaitteisiin lähtien erilaisista palvelu- ja sovellusideoista. Open Information on kasvanut viime aikoina huomattavasti. Liikevaihto on kaksinkertaistunut kahdeksan viime kuukauden aikana ja on n. 3 miljoonaa markkaa. Yrityksen palveluksessa on tällä hetkellä 16 kokopäiväistä työntekijää.

1.4 Projektin ympäristö

Projekti liittyy osana kokonaisuuteen missä tutkitaan nk. mobile life asioita. Tämän kokonaisuuden tavoitteena on kartoittaa mobiiliin toimimiseen liittyviä tarpeita, tekniikoita ja palveluja ja toteuttaa niitä. Kokonaisuutena on tavoite määritellä huomisen mobiilit toimintavälineet. Lisäksi tavoitteena on selvittää tämän toiminnan hallintaa, siihen liittyvää problematiikkaa ja suunnitella ratkaisuja tähän mobiilin elämän hallintaan.

1.5 Lopputuotteen tekijänoikeudet

Projektin lopputuote on tarkoitettu tutkimus- ja kehitystoimintaan. Projektiryhmä luovuttaa Open Information Oy:lle oikeudet muuttaa ja jatkokehittää tekemäänsä ohjelmistoa, luovuttaa tai siirtää nämä oikeudet edelleen kolmansille osapuolille, käyttää projektin lopputuotetta vapaasti yrityksen omassa tai muiden kolmansien osapuolien tutkimus- ja kehitystoiminnassa.

1.6 Projektin kustannusarvio

Projekti pyritään toteuttamaan mahdollisimman pitkälle käyttäen Teknillisen Korkeakoulun kurssin puitteissa tarjoamia resursseja sekä asiakkaalla jo olemassa olevia resursseja käyttäen. Jos projektille kuitenkin aiheutuu joitain materiaali- tai vastaavia kustannuksia, niistä vastaa projektin asiakas.

Projektin kannalta tarkemman kustannusrakenteen selvittäminen ja esittäminen ei ole tärkeää, koska projektin lopputuote on tarkoitettu tutkimus- ja kehityskäyttöön ja asiakas on projektin luonteesta johtuen sitoutunut projektin kaikkiin kustannuksiin.

1.7 Dokumentin rakenne

Dokumentin ensimmäinen kappale oli johdantoa projektiin. Kappaleessa kaksi määritellään lisää termeä projektisuunnitelman lukemisen helpottamiseksi ja kappaleessa kolme esitellään projektin organisaatio. Neljännessä kappaleessa projektin tavoite määritellään tarkasti ja erilaisten poikkeustapausten käsittelytavat kiinnitetään tähän liittyen. Viidennessä kappaleessa esitellään projektin resurssiarvio ja kuudennessa kappaleessa esitellään projektin keskeisimmät työkalut. Seitsemäs kappale esittelee projektin osituksen. Kappale kymmenen on projektin riskienhallintaprosessin dokumentaatio ja kappaleessa yksitoista tarkastellaan vaihtoehtoisia, mutta hylättyjä ratkaisuja.

2. Tekniset termit ja määritelmät sekä käytetyt käsitteet

Tässä kappaleessa selvitetään dokumentissä käytetyt tekniset termit ja määritelmät sekä projektin suunnittelussa käytetyt käsitteet.

2.1 Tekniset termit ja määritelmät

2.2 Raportin käsitteistö

3. Projektin organisaatio

Tässä kappaleessa esitellään projektin organisaatio. Seuraavissa kappaleissa esitellään projektiryhmän jäsenet, asiakkaan edustaja(t) ja kunkin projektiryhmän tehtävät ja vastuut projektissa.

3.1 Projektiryhmä

Projektiryhmän www-sivu löytyy osoitteesta www.iki.fi/miika/mobssh ja sen ylläpidosta vastaa Miika Komu. Ryhmän jäseniin saa parhaiten yhteyttä sähköpostitse ja yleisessä tapauksessa kannattaa ottaa yhteyttä ryhmän projektipäällikköön, Tuomo Saareen, tuomo.saari@hut.fi. Muiden ryhmän jäsenten yhteystiedot löytyvät taulukosta 3.1.

Taulukko 3.1 Projektiryhmän yhteystiedot

Tuomo Saari
Puhelin: 040 50 59 159
E-mail: tuomo.saari@hut.fi 
WWW-kotisivu: -
 
Tuomo Saari toimii MobSSH projektiryhmän projektipäällikkönä. Hänen tehtäviinsä kuluu projektin käytännön organisointi sekä väliraporttien ja vastaavien dokumenttien kirjoittelu. Lisäksi hän vastaa projektin prosessien laadusta.  Tämä sopii hyvin, koska Tuomon tausta on Tuotantotalouden osastolta, jossa hän opiskelee neljättä vuotta projektinhallintaa ja yritysstrategiaa sekä sivuaineenaan ohjelmistotuotantoa. Tuomon erityisosaaminen kattaa erilaisia projektinhallinnan järjestelmiä ja mielenkiinnolla odotamme, onko niistä mitään hyötyä tässä projektissa.
 Tero Nordström
Puhelin: 050 53 64 178
E-mail: tero.nordstrom@hut.fi
WWW-kotisivu: http://www.niksula.cs.hut.fi/~tenordst/
 
Tero Nordström toimii projektissa tietoturva-asiantuntijana. Lisäksi implementoinnin laatu kuuluu hänen vastuualueeseensa. Tero opiskelee neljättä vuotta tietotekniikan laitoksella pääaineenaan tietoliikenneohjelmistot ja sivuaineenaan sulautetut järjestelmät. Hän tuntee hyvin erilaiset tietoturva-algoritmit ja menetelmät. Lisäksi hän hallitsee hyvin TCP/IP protokollan.
 Kristian Slavov
Puhelin: 050 58 31 970
E-mail: kslavov@cc.hut.fi
WWW-kotisivu: http://www.hut.fi/~kslavov
 
Kristian opiskelee neljättä vuotta tietotekniikkaa ja lukee pääaineenaan tietoliikenneohjelmistojen protokollatuotannon säie. Tämän vuoksi hän sopii kuin nyrkki silmään vastaamaan tämän projektin protokollan toteutuksesta ja tähän liittyvistä ongelmista. Lisäksi Kristianilla on työelämän kokemusta protokollien toteuksessa vaadittavien tilakoneiden toiminnasta ja viestien välittelystä.
 Antti Järvinen
Puhelin: 050 582 7617
Email: antti.j.jarvinen@hut.fi
WWW-kotisivu: -
 
Antti Järvinen toimii projektiryhmässä dokumenttipäällikkönä vastaten dokumenttien mallipohjista, dokumenttien ajantasaisuudesta ja niiden palautuksesta vaiheiden lopussa. Antti opiskelee neljättä vuotta tietotekniikan koulutusohjelmassa pääaineenaan tietoliikenneohjelmistojen protokollatuotannon säie. Varsinaisessa toteutuksessa Antti huolehtiikin luontevasti SSH protokollan toiminnasta. Sulautettujen järjestelmien sivuaineopinnot ja aikaisempi kokemus työelämässä auttavat myös luotettavan järjestelmän rakentamisessa.
 Miika Komu
Puhelin: 050-3269103
E-mail: mkomu@cc.hut.fi
WWW-sivu: http://www.iki.fi/miika/
 
Miika on cvs- ja webvastaava ja hoitaa Mikan kanssa terminaaliemuloinnin ja käyttöliitymän suunnittelun ja koodauksen. Miika on tällä hetkellä webmasterina TML:ssa ja on graafisesti suuntautunut ihminen, joten valinnat webmasteriksi ja käyttöliittymävastaavaksi olivat luonnollisia.
 
Miikan kiinnostuksen kohteita tietotekniikan alalla ovat tietoliikenneohjelmointi ja tietoturvallisuus, jotka selittävät myös pääaineen (tietoturva) valinnan ja kiinnostuksen ja sovellusmahdollisuudet ssh-projektiin. Miikalla (ja tietenkin koko ryhmällä) on mahdollisuus projektin aikana saada kokemusta suuremman kaliiberin tietoturvasovelluksesta ja oppia sulautetuista järjestelmistä, josta Miikalla on hyvin vähän kokemusta.
 Mika Kousa
Puhelin: 040-7445362
E-mail: mkousa@cc.hut.fi
WWW-sivu: -
 
Mika on neljännen vuoden opiskelija tietotekniikan koulutusohjelmassa, pääaineena tulee olemaan tietoliikenneohjelmistojen suunta. Sivuainekin tulee olemaan jokin tietotekniikan koulutusohjelmasta.
 
Mika toimii MobSSH-projektin käyttöliittymävastaavana. Hän on myös mukana osa-aikaisesti tietoliikenneprotokollien suunnittelussa, koska Mikan kiinnostuksen kohteita ovat mm. TCP/IP-protokollaan liittyvät asiat.
 Jukka Ahonen
Puhelin: 040-7555652
E-mail: Jukka.Ahonen@iki.fi
WWW-sivu: -
Jukka on ryhmän EPOC arkkitehtuurivastaava ja on vastuussa     integraatiotestauksesta.Lisäksi hän osallistuu tietoturva-algoritmien porttaukseen ja toteutukseen Teron apuna. Hänellä on pääaineena tietoliikenneohjelmistot ja sivuaineena sulautetut järjestelmät. Jukalla on entuudestaan kokemusta ohjelmoinnista PDA-laitteille (Palm OS) ja hän on kiinnostunut tutustumaan EPOC ympäristöön mahdollisimman perusteellisesti.

3.2 Muut sidosryhmät

Projektin asiakkaana ja ohjaajana toimii Arto Sinkkonen Open Information Oy:stä. Hän on Open Information Oy:n toimitusjohtaja.

Asiakkaan kanssa tehdyn sopimuksen perusteella projektitryhmällä ei ole oikeutta julkaista projektin muita sidosryhmiä ilman Open Informationin erillistä lupaa ja toistaiseksi muut projektin sidosryhmät jäävät salaisiksi.

4. Projektin tavoitteet ja päättäminen

Tässä kappaleessa esitellään projektiryhmän ja asiakkaan tavoitteet MobSSH projektissa. Esiteltyjen tavoitteiden perusteella kootaan yhteen projektin tavoite.

4.1 Projektiryhmän tavoitteet

Projektiryhmän ensisijaisena tavoitteena on suorittaa kurssi Tik-76.115 mahdollisimman menestyksekkäästi. Tämän tavoitteen saavuttamiseksi projektiryhmä pyrkii tuottamaan vaatimusten mukaisen tuotteen käyttäen yleisesti hyväksi todettuja toimintatapoja ja omaa laatujärjestelmäänsä.

4.2 Asiakkaan tavoitteet

  1. Taso 1 on rfc minimitaso, joka täytyy toteuttaa ssh1-clientista. Tämä tarkoittaa alla listattuja asioita 2-5,7 (must)
  2. tietoturva algoritmit crc, rc4, des, md5, 3des (must)
  3. autentikointi salasanalla (taso 1) ja rsa autentikointi (taso 2) (must)
  4. itse ssh1 protokolla ja avainten vaihto (must)
  5. rsa-avainten generointi erillisellä ohjelmalla (must)
  6. Taso 2 sisältää valitut lisäasiat.. Näitä ovat scp-toiminto (eri sovelluksena), RSA-salaus ja avainten generointi (erillinen ohjelma) ja salattu yhteys. (must)
  7. Terminaaliemulointi vt100 emulointina (must)
  8. Projektin toteutuminen aikataulussa on tärkeä (must)
  9. port forwarding on piirre, jota ei toteuteta
  10. .rhosts-tyyppinen autentikointi on piirre, jota ei toteuteta
  11. laatukriteerien noudattaminen laatukäsikirjan mukaisesti (taso 1, useful) (taso 2, must)
  12. Projektilla on jatkuvasti toimitettavissa oleva versio. (must)

4.3 Projektin tavoitteet

Projektin tavoitteena on toteuttaa vaatimusmäärittelyssä esitellyn tason kaksi mukainen ohjelmisto asiakkaan vaatimukset toimintatavoista huomioon ottaen siten, että kenenkään projektiryhmän jäsenen opinnot Teknillisessä Korkeakoulussa eivät tule uhatuksi ja siten, että projektiryhmä saa suoritettua kurssin Tik-76.115 lukuvuoden 2000-2001 aikana. Tavoitteen saavuttamiseksi projektiryhmä ja asiakas (Arto Sinkkonen) sitoutuvat eri sopimuksella tässä projektisuunnitelmassa esitettyihin järjestelyihin ja toimintatapoihin eri tapauksissa sekä sitoutuvat noudattaan projektille erikseen laadittua laatukäsikirjaa projektin onnistumisen varmistamiseksi. Jos kappaleen 6.4 esittämin perustein joudutaan karsimaan ohjelmiston vaatimuksista ja projektin tavoitteista, niin toteutuksen minimitaso on vaatimumäärittelyssä esitetty taso yksi ja lopputuotteen eri ominaisuuksista karsitaan kappaleessa 7.1 esitetyn järjestyksen perusteella. Tavoitteiden karsimisesta pyritään kuitenkin sopimaan tapauskohtaisesti asiakkaan kanssa.

4.4 Projektin keskeyttämis- ja tavoitteiden uudelleenarviointikriteerit

Tässä kappaleessa selvitetään projektin tavoitteiden uudelleenarviointi- ja projektin keskeyttämiskriteerit, jos projektin jossain vaiheessa nämä toimenpiteet katsotaan tarpeellisiksi.

Projekti pyritään saattamaan loppuun kaikisssa olosuhteissa opiskelijatyö luonteensa vuoksi ja jos projekti joutuu ongelmiin, on ensisijaisena keinona projektin lopputuotteen ominaisuuksien karsiminen. Projekti voidaan kuitenkin keskeyttää projektiryhmän ja asiakkaan yhteisellä päätöksellä, jos projektin tilanne tätä vaatii. Tätä päätöstä tehtäessä tulee olla läsnä vähintään viisi projektiryhmän jäsentä (kuolemantapaukset ja vakavat sairaudet vähentävät lukumäärää vastaavasti) ja asiakkaan puolelta joko ohjaaja tai varsinainen asiakashenkilö tai heidän erikseen nimetyt edustajansa.

Projektin lopputuotteen laajuudesta karsitaan tarvittaessa kappaleessa 7.1 esitettävän prioriteettijärjestyksen mukaisesti (matalin prioriteetti on ensimmäinen ominaisuus, josta karsitaan) seuraavissa tapauksissa.


Jos tarpeellista, tavoitteiden karsiminen tapahtuu asiakkaan läsnäollessa ja asiakkaalla on mahdollisuus antaa projektiryhmän käyttöön ylimääräisiä resursseja ja/tai työapua siten, että se on projektiryhmän käytössä mahdollisimman nopeasti, kuitenkin viimeistään viiden työpäivän kuluttua siitä, kun asiakas on tullut tietoiseksi asiasta.

4.5 Projektin päättämiskriteerit

Projekti päättyy viimeistään 24.4.2001 tai projektin loppuraportin luovutuksen yhteydessä. Projektin loppuraportti luovutetaan päätöskokouksessa, joka järjestetään viimeistään 24.4.2001. Jos kokousta ei jostain syystä voida järjestää, niin se ei estä projektin päättymistä. Projekti voidaan päättää aikaisemmin myös muilla asiakkaan kanssa erikseen sovittavilla perusteilla. Projektin päättymisen jälkeen pyritään resurssien ja mahdollisuuksien mukaan järjestämään päätöstilaisuus, jossa projektin kaikki osapuolet ovat läsnä ja projektin loppuminen tulee kaikkien tietoon.

Projektin lopputuotteena toimitetaan projektiryhmän tuottama viimeisin version SSH1 protokollasta EPOC ympäristöön ja kaikki käyttöön liittyvät dokumentit, joista sovitaan myöhemmin. Asiakkaan mahdollisesta tarvitsemasta koulutuksesta, tuesta, asennus- tai käyttöönottopalvelusta projektin lopputuotteen osalta sovitaan erikseen.

5. Projektin resurssit

Tässä kappaleessa esitellään projektin tärkeimmät resurssit ja niiden saatavuus projektin eri vaiheissa.

5.1 Henkilöstöresurssit

Taulukkoon 5.1 on kerätty kaikkien projektiryhmän jäsenten arvio käytettävistä olevista tunneista projektin eri vaiheissa. Arviot perustuvat projektiryhmän jäsenten henkilökohtaisiin arvioihin.
 
Taulukko 5.1 Projektiryhmän resurssiarviot projektin eri vaiheissa
  Tuomo Saari Tero Nordström Jukka Ahonen Antti Järvinen Kristian Slavov Miika Komu Mika Kousa Yhteensä
PS  50  50  20   20  10  30  30  165 
T1  25  30  40  35  30  30  30  220 
T2  25  30  40  40  40  30  30  235
T3  25  40  40  20  50  40  35  250
T4  25  30  30  40  40  40  25  270
LU  50  20  30  45  30  30  50  260
Yhteensä  200  200  200  200  200  200  200  1400

Resurssisuunnittelun rajoitteina ovat seuraavat seikat

6. Projektissa käytettävät menetelmät ja työkalut

Projektin laatukäsikirja määrittelee projektissä käytettävät menetelmät ja seurannan ja raportoinnin työkalut. Laatukäsikirjaa voidaan päivittää projektin kuluessa, koska projektin eksploratiivinen luonne ei anna mahdollisuuksia määritellä tarkasti kaikkia toimintapoja, ennen kuin projektin ensimmäisen prototyyppivaiheen kokemukset ovat projektiryhmän käytettävissä. Projektin kehitys- ja versionhallintatyökaluista keskeisimmät on listattu versionumeroineen seuraavassa:

Käyttöjärjestelmä:
-Microsoft Windows 2000 Professional

Ohjelmistokehitystyökalut:
-Microsoft Visual Studio 6.0, Enterprise Edition
 (sisältää Microsoft Visual C++ 6.0)
-Symbian EPOC Release 5 SDK (Software development kit)

Versionhallinta:
-CVS (Concurrent Versions System) versio 1.10.8

Asiakas toimittaa projektin käyttöön tarvittavat laitteisto- ja ohjelmistoresurssit TKK:n tarjoamien resurssien lisäksi.

7. Projektin ositus, vaiheistus ja resurssointi

Tässä kappaleessa esitellään kootusti projektin päävaiheet ja resurssoinnin periaatteet. Projektin lopputuote on jaettu tuotepohjaisiin [1] osiin projektin työnjaon ja resurssoinnin perustaksi.

7.1 Projektin ositus

Projektin lopputuotteen PBS on esitetty kuvassa 7.1
Projektin PBS
Kuva 7.1 Projektin PBS

Kuvassa 7.1 esiintyvät roomalaiset numerot indikoivat eri osien prioriteettijärjestystä, jonka mukaan projektia lähdetään toteuttamaan ja järjestystä jossa projektin osista tarvittaessa karsitaan.

Projektin toteutuksen kannalta on siis olemassa neljä pääosaa, jotka ovat


Seuraavassa kappaleessa selvitetään, miten toteutus on pääpiirteissään suunniteltu.

7.2 Projektin vaiheistus

Projekti etenee kurssin esimerkkiprosessin mukaisissa vaiheissa. Projektin päävaiheet ovat


Projektin tarkempi vaiheistus löytyy MS Project muodossa tästä.

Projektin suunnitteluvaiheen aikana projekti perustetaan ja sen toiminta organisoidaan. Lisäksi projektin asiakkaan ongelma analysoidaan ja sen toteutus mitoitetaan projektin aikatauluun ja saatavilla oleviin resursseihin sopivaksi. Analyysin perusteella tarkennetaan asiakkaan ongelmaa ja pyritään löytämään kaikkia osapuolia tyydyttävä kompromissi projektin toteutuksesta.

Toteutus- ja luovutusvaiheissa edetään USDL:n hengessä käyttäen seuraavaa lähestymistapaa


Tällä tavoin etenemällä pyritään säilyttämään aina "toimiva" versio, johon uusia osia voidaan liittää. Lähestymistapa auttaa tunnistamaan eri osien integraatioon liittyvät ongelmat mahdollisimman aikaisessa vaiheessa testaamalla koko ajan "koko" järjestelmällä saavutetaan myös koodin laadun kannalta hyvä tulos. Ohjelmiston kehitystä tämä lähestymistapa tukee siinä mielessä, että kaikkien osien implementointi voidaan aloittaa heti ensimmäisessä vaiheessa ja rajapintojen määrittelyyn jää enemmän joustovaraa verrattuna tilanteeseen, jossa rajapinnat kiinnitettäisiin heti projektin alussa.

Projektin luovutusvaihe keskittyy testaukseen aidoilla EPOC - päätelaitteilla ja erilaisten langattomuudesta ja tiedonsiirtonopeudesta johtuvien ongelmien kartoittamiseen ja ratkaisuehdotusten muotoiluun jatkokehitystä varten.

8. Seuranta ja ohjaus

Projektin seurannan ja ohjauksen prosessit pohjautuvat kurssin ja asiakkaan esittämiin vaatimuksiin. Tarkat seuranta- ja ohjausprosessit on dokumentoitu projektin laatukäsikirjassa.

9. Standardit, direktiivit ja määräykset

Projekti ei noudata mitään ulkoista direktiiviä tai määräyskokoelmaa. Projektilla on oma laatukäsikirja, joka selvittää tärkeimmät toimintatavat. Ainoa projektia koskettava standardi on vielä luonnosvaiheessa oleva SSH1 standardi, jonka pohjalta projektin lopputuote tehdään.

10. Riskienhallintasuunnitelma

Projektin riskienhallintaprosessi on määritelty tarkasti projektin laatukäsikirjassa. Prosessi alkaa ensimmäisellä tunnistusvaiheella, jonka määrittely, toteutus ja tulokset on dokumentoitu projektisuunnitelmaan. Riskienhallinnasta tulee oma kokonaisuutensa projektin hallinnassa ja projektisuunnitelman riskienhallintasuunnitelmaa (tämä kappale) ei tulla päivittämään, vaan riskienhallintaprosessi siirtyy omaksi kokonaisuudekseen.

10.1 Ensimmäisen tunnistusvaiheen määrittely ja toteutus

Projektin suunnitteluvaiheessa pidettiin riskienhallintakokous, jossa soveltamalla Delphi-metodia [2] ensin kaikki projektiryhmän jäsenet ja asiakas itsenäisesti yrittivät tunnistaa mielestään kriittisimmät riskit. Riskit tuli luokitella vakavuuden mukaan asteikolla 1 - 5 (5 erittäin vakava), siten että riskien vakavuusarvioita voitiin verrata toisiinsa. Riskien toteutumistodennäköisyyksien ennustamisesta päätettiin luopua, koska ryhmällä ei ole kokemusta ohjelmistoprojekteista ja itsenäisesti toteutetut arviot voivat skaalautua hyvinkin eri tavalla ja tulosten validius kärsii. Riskit arviotiin siis yksinkertaisesti vakavuuden perusteella ja siten, että kannattaako riskin toteutumisen estämiseksi tehdä vastatoimia vai ei. Projektin mahdollisuudet siirtää riskejä kolmansille osapuolille ovat varsin heikot, joten siirtomahdollisuuden arvioinnista luovuttiin.

Jokaiseen tunnistettuun riskiin identifioitiin riskin indikaattorit, arvioitiin vaikutus sekä suunnitteltiin vastatoimet itsenäisesti ja tämän jälkeen tulokset kerättiin yhteen ja lajiteltiin siten, että samaa riskiä kuvaavat tunnistukset tulkittiin ko. riskin "osumiksi". Mitä enemmän yksittäinen riski sai "osumia", eli riippumattomia tunnistuksia, sitä tarkemmin se otettiin huomioon hallintasuunnitelmaa laadittaessa. Tästä vaiheesta eteenpäin riskienhallinta siirtyi noudattamaan projektin laatukäsikirjassa määriteltyä prosessia.

Edellä kuvattu riskienhallinnan ensimmäinen vaihe toteutettiin 5.10 - 9.10.2000 ja ensimmäinen varsinainen riskienhallintakokous oli 9.10.2000. Kokouksesta on olemassa myös normaali kokousmuistio, mutta kokouksen tulokset esitellään seuraavassa kappaleessa taulukossa 10.1.

10.2 Ensimmäisen riskienhallintakokouksen tulokset

Taulukko 10.1 Ensimmäisen riskienhallintapalaverin tulokset
Riskin Numero
Riskin Nimi
Indikaattorit
Hallintakeinoja
Riskin seuraukset ja vakavuus
Toteutetut hallintakeinot
 1
Epätasainen työnjako ryhmän sisällä
  • Yhden ryhmän jäsenen aikataulut lipsuvat.
  • Jatkuvaa myöhästelyä
  • Huonoja selityksiä, ongelmaa tiedostetaan, mutta ei tunnusteta
  • Pyritään suunnittelun keinoin tasaiseen työnjakoon
  • Asetetaan päällekkäisyyksiä tehtäviin, eli kukaan ei toimi yksin
  • Seurataan toisten toimintaan
  • Huomioidaan henkilökohtaiset aikataulut projektin työnjaossa
  • Yksi ryhmän jäsen lopettaa, 4
  • Aikataulu kärsii, 2
  • Muut ovat toimettomia, 2
  • Projektin laatukäsikirja määrittelee työtavat, jotka toteuttavat esitetyt hallintakeinot 
 2
 Tietoturva-algoritmien porttaus EPOCiin ei onnistu
 -
  • Analysoidaan koodia etukäteen
  • Pyritään optimoimaan koodia jo valmiiksi EPOCille
  • Varaudutaan tilanteeseen, jossa algoritmit tulevat koodattaviksi projektin suunnittelussa
  • Tietoturvaosuuden työmääräarvio ja resurssointi joudutaan uusimaan, 2
  • Tietoturvan tasoa joudutaan arvioimaan uudestaan, 4
  • Projektin resurssoinnissa riski on huomioitu ja käyttöliittymän kehityksestä voidaan tarvittaessa allokoida lisää resursseja
  • Asiakas on lupautunut tarvittaessa antamaan projektille lisäresursseja 
 3
Valmiiden ohjelmistorutiniien toimimattomuus EPOC-ympäristössä 
- 
  • Jatkuva testaaminen viallisen rutiinin tai ongelmakohdan tunnistamiseksi
  • Valmis ohjelmistorutiini ei toimi EPOCissa, 4
  • Projektiryhmän kaikki osapuolet ovat tietoisia mahdollisesta ongelmasta ja se kuuluu projektin luonteeseen. Ongelmat tarkastellaan tapauskohtaisesti. 
4
 Toteutus on teknisesti liian vaativa projektiryhmälle
  •  Projektiryhmän sisällä syntyy epätoivoa, sisäisiä konflikteja ja panostus projektiin vähenee tekosyiden varjolla
  • Asiakas antaa projektiryhmälle asiantuntija- ja koodausapua tarvittaessa.
  • Pyritään käyttämään jo olemassa olevia toteutuksia ja valmiita ja toimiviksi todettuja ohjelmistorutiineja
  • Projektin lopputuotteesta ei tule vaatimusmäärittelyn mukainen, 5 
  • Projektiryhmän kaikki osapuolet ovat tietoisia mahdollisesta ongelmasta ja se kuuluu projektin luonteeseen. Asiakas on lupautunut auttamaan projektiryhmää tarpeen vaatiessa. 
5
Projektin lopputuotteen sisäinen toimimattomuus tai vajavainen toimivuus 
- 
  • Runsas testaaminen eri ympäristöissä
  • Simuloidaan erilaisia virhetilanteita testeissä
  • Testaus useita eri SSH-servereitä vastaan
  • Ohjelmistoon jää harvoin esiintyviä virheitä testauksesta huolimatta, 2 
  • Projektin laatukäsikirja määrittelee testaus- ja toimintatavat, jolla ongelmat pyritään välttämään. Projektin luonteesta johtuen niitä ei voitane täysin poistaa ja ongelmista neuvotellaan tapauskohtaisesti 
6
EPOC simulaattori ja todellisen EPOC laitteen välillä havaitaan eroja
- 
  • Pyritään mahdollisuuksien mukaan testaamaan projektin välivaiheita myös todellisilla laitteilla 
  • Projektin lopputuote toimii simulaattoriympäristössä, mutta ei varsinaisilla laitteilla, 3
  • Joudutaan etsimään ratkaisuja ongelmiin, jotka eivät ole projektin tarkoitus, 2
  • Projektin luonteen mukaisesti kuvatut ongelmatilanteet ovat mahdollisia ja ongelmien tunnistaminen ja kokemusten kerääminen on yksi projektin tarkoitus. Ongelmista ja niiden vaikutuksesta projektiin neuvotellaan tapauskohtaisesti. 
7
 Kommunikaatio- ongelmat asiakkaan ja projektiryhmän välillä
  • Sovitut aikarajat venyvät
  • Rutiininomaisissa palavereissa tulee ilmi vaatimuksia, joista projektiryhmä ei ole tietoinen
  • Asiakas sitoutetaan noudattamaan projektin laatukäsikirjaan kirjattuja toimintatapoja ja allokoi riittävästi aikaansa projektille
  • Asiakkaan edusja nimeää itselleen varahenkilön, johon projektiryhmä voi tarvittaessa ottaa yhteyttä
  • Projektiryhmä ei saa palautettua kurssin vaatimia dokumentteja ajoissa, 5
  • Projektin tavoitteista joudutaan karsimaan projektiryhmästä riippumattomista syistä, 4
  • Projektin laatukäsikirja määärittelee oikeaoppiset toimintavat, joita asiakas on sitoutunut noudattamaan. 
8
 SSH-prokollan spesifikaatio ei ole riittävän yksityiskohtainen
- 
  • SSH-spesifikaatioon tutustuttaessa tutustutaan myös olemassa olevaan koodin mahdollisten epäselvyyksien välttämiseksi
  • Otetaan yhteyttä laatijaan ja kysytään neuvoa
  • Aiheuttaa ennakoimatonta työtä, 2 
- 
9
Asiakas ei sitoudu projektiin riittävän hyvin 
  • Projektiryhmä ei sisäisesti ole varma asiakkaan vaatimuksista ja sitoutumisesta projektiin
  • Asiakkaan kanssa sovitut aikarajat venyvät
  • Asiakas sitoutuu projektin tavoitteeseen
  • Asiakkaalle selvitetään projektiryhmän omat tavoitteet
  • Projektin ohjaaminen asiakkaan puolelta ei ole riittävää, projektin suuntaminen teknisesti kärsii, 3
  • Asiakkaan lupaamat osuudet projektiin eivät pysy aikataulussa, 4
  • Projektiryhmän motivaatio kärsii, 4
  • Asiakas hyväksyy projektisuunnitelman mukaisen tavoitteenasettelun ja sitoutuu pyrkimään tähän tavoitteeseen. 
10
 Kehitystyökalujen käyttöönotto osoittautuu ennakoitua vaikeammaksi
  • Aikaa kuluu koodaamiseen, mutta tulosta ei synny
  • Aikaa kuluu manuaalisiin operaatioihin, jotka muitten kokemusten perusteella tulisi olla automaattisia
  • Varataan valmiiksi aikaa uusiin työkaluihin tutustumiseen ja kokeillaan niiden toimintaa "Hello World" tason sovellutuksilla
  • Tutustutaan manuaaleihin
  • Projektin työmääräarviot pettävät, 3
  • Projektiryhmän jäsenten turhautuminen vaikuttaa negatiivisesti motivaatioon, 4
- 

11. Hylätyt ratkaisuvaihtoehdot

Projektin alkuvaiheessa valinta kohdistui lähinnä siihen, että toteutetaanko SSH-protokollan ensimmäinen vai toinen versio. Teknisen analyysin perusteella protokollan versio 2 on kryptografisesti parempi, minkä johdosta yksittäiseen pakettiin joudutaan laittamaan paljon enemmän muuta kuin pelkkää hyötydataa verrattuna ykkösversion pakettiin. Myös paketin eheyden tarkistamiseen tarvittavien tarkistussummien laskeminen vie enemmän aikaa. Koska projektissa toteutettava SSH client käyttää tiedonsiirtoon hitaita langattomia yhteyksia ja laitteistojen tehot ovat pienet, protokollan ykkösversio todennäköisesti soveltuu tehtävään paremmin. Lisäksi protokollan ykkösversion palvelintoteutuksia on useita, jolloin myös clientin yhteensopivuutta pystytään paremmin testaamaan.

Muita ratkaisuvaihtoehtoja ei ollut tarjolla.

Lähdeluettelo

[1] The Handbook of Project Based Management, J Rodney Turner, Second Edition, McGraw Hill Ltd, 1998
[2] Software Project Management, Bob Hughes, Mike Cotterell, Second Edition, McGraw-Hill, 1999

Liiteluettelo

Projektin laatukäsikirja
Vaatimusmäärittely

Valid HTML 4.0! Valid CSS! URL: http://www.niksula.cs.hut.fi:80/~mkomu/mobssh/julkaisut/projektisuunnitelma.html
Viimeksi päivitetty: 17.10.2000