T Ohjelmistokehitysprojekti I Projektisuunnitelma (PP)

Transkriptio

1 T Ohjelmistokehitysprojekti I Projektisuunnitelma (PP) Versio Päiväys Muokkaaja Kuvaus Kattilamäki Kattilamäki Palautettava versio Rönkkö Rönkkö Lisätty muutosloki 1. Johdanto Yleiskatsaus projektiin Valpas Käytetyt termit Sidosryhmät ja jäsenet Organisaatiokaavio Yhteystiedot Tavoitteet ja lopettamiskriteerit Asiakkaan tavoitteet Projektiryhmän tavoitteet Henkilökohtaiset oppimistavoitteet Projektin keskeytys- ja lopetuskriteerit Resurssit ja budjetti Henkilökunta Materiaalit Budjetti Työkalut ja menetelmät Menetelmät Iteratiivinen kehittäminen Iteraatiosuunnittelu Dokumentointi

2 5.1.4 Riskien hallinta Tuntiraportointi Ohjelmiston koon raportointi Kommunikaatio Iteraatiodemo Virheiden seuranta Versionhallinta Ohjelmointikäytännöt Vertaistestaus Vaatimusten hallinta SEPA - Heuristinen arviointi SEPA - Design Patterns SEPA - Static Methods SEPA Refactoring Työkalut Standardit Jaksotus Aikataulu Projektisuunnnittelu Projektin suunnittelu (PP) Ensimmäinen iteraatio Toinen iteraatio Riskienhallinta Prosessi Riskikategoriat TOP 5 riskit Asiakas Teknologia Sidosryhmä Projektinhallinta Järjestelmä Kurssi Laillinen / Kaupallinen Lähteet Johdanto Tämä dokumentti on ryhmän Neptune projektisuunnitelma Teknillisen Korkeakoulun kurssin T Ohjelmistokehitysprojekti I puitteissa toteutettavaan projektiin. Asiakkaana toimii Indagon Oy. Indagon Oy on mobiilipaikannukseen erikoistunut yritys. Projekti on tarkoitus suorittaa aikavälillä Tämä dokumentti toimii epävirallisena sopimuksena projektiin liittyvien osapuolien välillä. Projektin suorittava ryhmä käsittää kahdeksan kurssin opiskelijaa, jotka toimivat erilaisissa ohjelmistoprojektille tyypillisissä rooleissa. Kurssin toimesta projektille on asetettu toimintavaatimuksia sekä 2

3 noudatettavia käytäntöjä. Ne on mainittu tässä dokumentissa. Projektin aihe on Indagon Oy esittämä ja kuvataan seuraavassa kappaleessa. 1.1 Yleiskatsaus projektiin Valpas Nykypäivänä viranomaiset ovat asettaneet vaatimuksia palohälyttimille, joita on pakko olla julkisissa ja riittävän isoissa rakennuksissa. Hälyttimiä tulee voida tarkkailla ja varmistaa luotettavasti niiden toimivuus. Järjestelmä vastaa tähän tarpeeseen ja toteuttaa toiminnallisuuden Tetra-verkossa. Projektin tarkoitus on ensimmäisessä vaiheessa toteuttaa prototyyppi järjestelmästä, jonka perusteella voidaan tarpeen mukaan jatkokehittää kaupallinen tuote. Kuva 1 - Projektin toteuttama järjestelmä Projektin tarkoituksena on kehittää TETRA-verkon päällä toimiva simulaatio, jolla on tarkoitus testata tulevaisuudessa toimivan järjestelmän luotettavuutta. TETRA-puhelin voidaan yhdistää sarjaportin kautta PC:hen, jolloin puhelinta voidaan käyttää AT Command Interfacen avulla. Tämä PC simuloi ilmoitinkeskusta ja laskee perille tulleita viestejä ja lähetettyjä viestejä. TETRA-verkon toisella laidalla on EPA, joka tarjoaa palveluita rakennettavalle Valppaalle. EPA:n kautta Valpas pystyy lähettämään SDSviestejä kuten myös vastaanottamaan niitä. Tärkeää projektin kannalta on pystyä tilastoimaan järjestelmän luotettavuutta. Lisäksi Valppaaseen tarvitaan www-palvelu, jolla järjestelmän toimintaa voidaan ylläpitää. 3

4 1.2 Käytetyt termit Termi/Lyhenne Selitys EPA Downlink Edustapalvelin, Tetra-verkon reunalla oleva palvelin, joka tarjoaa Tetraverkon palveluita helpommin käytettävällä tavalla sovelluksille. Kanava jota pitkin viesti kulkee Valppaalta puhelimelle. Ilmoitinkeskus Rakennuksessa oleva keskus, johon kaikki rakennuksessa olevat hälytin anturit/sensorit on kytketty. Linjavika MTT Vika yhteydessä Valppaan ja puhelimen välillä. Mobile Telematics Terminal. Indagon Oy:n kehittämä laite, joka osaa kertoa koordinaatit paikasta, jossa laite sijaitsee. Ryhmäosoite SDS Tetra TMR880 Uplink Valpas Virve Yksilöosoite (K)loc SEPA TETRA-verkon "puhelinnumero", jonka vastaanottajina on useampia tahoja samaan aikaan. Tetra-verkon vastine SMS-viestille. SDS-viestejä on useampia tyyppejä, joista kolmella on kiinteä pituus ja neljäs on vaihtelevan pituinen. Terrestial Trunked Radio (Tetra-verkko on viranomaiskäyttöön tarkoitettu puhelinverkko) Nokian puhelinmalli TETRA-verkkoon. Kanava jota pitkin viesti kulkee puhelimelta Valppaalle. Toteutettava järjestelmä (ValvontaPalvelinSysteemi) Suomessa oleva viranomaisverkko joka toimii tetra-järjestelmällä. Vastaa TETRA-verkossa tavallista puhelinnumeroa. (Kilo) Lines Of Code, Koodirivien määrä (tuhansissa) Software Engineering Practice. Kurssin vaatima selvitys käytettävistä menetelmistä. 2. Sidosryhmät ja jäsenet Taulukko 1 - Käytetyt termit 2.1 Organisaatiokaavio Liitteessä 1 on esitetty projektin organisaatiokaavio ja projektin sidosryhmät. Täydelliset yhteystiedot löytyvät projektin kotisivuilta (Wiki) ja ne on jätetty tästä dokumentista pois tarkoituksella. 4

5 Kuva 2 - Sidosryhmien väliset riippuvuudet 2.2 Yhteystiedot Nimike Nimi Luennoija Jari Vanhanen jari.vanhanen#hut.fi Laatupalkinto Vesa Luomala vesa.luomala#accenture.com Mentor Kari Suhonen kari.suhonen#hut.fi Asiakas Markus Maanoja markus.maanoja#indagon.com Tekninen neuvoja Pete Lyly peteveikko.lyly#everkot.fi Projektipäällikkö Markus Kattilamäki markus.kattilamaki#hut.fi Pääarkkitehti Tuukka Laakso tjlaakso#cc.hut.fi Laatupäällikkö Kirsi Rönkkö catangel#iki.fi Kehittäjä Mikko Halttunen mikko.halttunen#hut.fi Kehittäjä Markku Huttunen mahuttun#cc.hut.fi Kehittäjä Antti Kettunen ajkettun#niksula.hut.fi Kehittäjä Mikko Närjänen mtnarjan#cc.hut.fi Kehittäjä Antti Poikela aspoikel#cc.hut.fi Taulukko 2 - Yhteystiedot Projektin Wiki löytyy osoitteesta ja vaatii käyttäjältään käyttäjätunnuksen ja salasanan. 3. Tavoitteet ja lopettamiskriteerit Projektin tavoitteena on rakentaa seurantajärjestelmän prototyyppi jonka avulla voidaan selvittää tuotteen kaupalliset ja jatkokehitykseen liittyvät näkymät. Projektiryhmälle kurssi toimii opetuksellisena harjoitustyönä, tarkoituksena syventää näkemystä ohjelmistoprojektiin ja erilaisiin ohjelmistoprojektille ominaisiin menetelmiin. 5

6 3.1 Asiakkaan tavoitteet ID Tavoite Täyttymiskriteeri A1 Mahdollinen kaupallinen tuote tuhansille käyttäjille Prototyypin onnistunut toteuttaminen A2 Teknisen neuvojan lopputyön tekeminen aiheesta A3 Aihealueesta oppiminen ja tietämyksen laajentaminen A4 Kaupallistamisen selvittäminen A5 Asiakkaan ohjelmistoprosessin kehittäminen A6 Tetra-verkon käytettävyyden lisäselvitys Lopputyön toteuttaminen Projektin menestyksekäs suorittaminen Prototyypin toimivuus Asiakkaan prosessien kehittyminen, asiakas toteaa itse. Prototyypin toimivuus ja skaalautuvuus Taulukko 3 - Asiakkaan tavoitteet 3.2 Projektiryhmän tavoitteet ID Tavoite Täyttymiskriteeri R1 Opintosuoritus hyvällä arvosanalla Kurssin suoritus hyvällä arvosanalla R2 Aihealueesta oppiminen R3 Laajemmassa ohjelmistoprojektissa toimiminen R4 Laadukkaan ja asiakkaalle arvoa tuottavan ohjelmiston toimittaminen Oppimiskokemusten kerääminen projektin jälkeen Projektin tyydyttävä suoritus Projektin lopputuotetta jatkokehitetään Taulukko 4 - Projektiryhmän tavoitteet 3.3 Henkilökohtaiset oppimistavoitteet Jäsen Oppimistavoite Kattilamäki Saada kokemusta ohjelmistoprojektin vetämisestä ja oppia tehokkaita menetelmiä projektin läpiviemiseksi. Laajentaa näkemystä ohjelmistoprojektista ja sen eri vaiheista. Laakso Oppia johtamaan kehittäjäryhmää ja saada kokemusta arkkitehdin tehtävistä 6

7 Rönkkö Oppia vetämään projektia paremmin, hallitsemaan sitä sekä oppia laadunvarmistukseen liittyviä asioita, sekä kehittyä testauksen saralla Taulukko 5 - Henkilökohtaiset oppimistavoitteet 3.4 Projektin keskeytys- ja lopetuskriteerit Projekti ja kurssin suorittaminen voidaan keskeyttää ryhmän yhteisellä päätöksellä jos jokin seuraavista tilanteista toteutuu Prototyyppi ei vastaa jatkokehityksen vaatimuksia Asiakas lopettaa projektin Kaksi tai useampi henkilö jättää ryhmän Kurssia ei ole enää mahdollista läpäistä Projekti päättyy viimeisen iteraation päätyttyä Tällöin dokumentit ja lopputuote toimitetaan viimeistään asiakkaalle kaikissa tapauksissa. Muita mahdollisia projektin lopetuskriteereitä voivat olla seuraavia edellyttäen että työ on toimitettu asiakkaalle. Käytettävän työmäärän täyttyminen Projektin valmistuminen ennen määräpäivää 4. Resurssit ja budjetti PP I1 I2 yht. Suunnittelu Dokumentointi 64, ,8 Infrastruktuuri 4, ,4 Luento 40, ,8 Palaveri Ohjelmointi Hallinnointi ,2 95,2 Opiskelu 20 51, ,6 Testaus 0 41,6 56,6 98,2 Kommunikaatio Muu Yhteensä ,2 516, Taulukko 6 - Kurssin edellisiin projekteihin perustuva arvio ajankäytöstä 7

8 4.1 Henkilökunta Jäsen I0 I1 I2 Yhteensä Kattilamäki Rönkkö Laakso Halttunen Huttunen Kettunen Närjänen Poikela Taulukko 7 - Arvioidut työmäärät kussakin iteraatiossa 4.2 Materiaalit Projektin kehitystyö tullaan pääosin suorittamaan projektiryhmän omilla laitteistoilla. Lisäksi ryhmällä on käytettävissään Teknillisen Korkeakoulun opiskelijoilleen tarjoamat laitteistot ja palvelut. (ATK-keskus ja Niksula) Paras mahdollinen tilanne olisi että jokaisella projektiin osallistuvalla olisi käytössään samanlainen kehitysympäristö ja alusta. Tämä on käytännössä mahdollista koulun tarjoamien koneiden puitteissa. Emme voi kuitenkaan vaatia ainoastaan niiden käyttöä kehitystyössä. Ympäristöissä ja työkaluissa pyritään mahdollisimman samankaltaiseen asetteluun. Indagon Oy mahdollistaa projektille testilaitteistoa ohjelmiston testausta varten: 1 kpl kannettava tietokone 1-3 kpl Tetra-verkon puhelinta MTT & antenni sijainnin määrittämiseksi 4.3 Budjetti Seuraavassa taulukossa on esitetty projektin teoreettinen budjetti. Se on laskettu arvioita käyttäen eikä asiakasta laskelman mukaisesti veloiteta. Osa kuluista kuten asiakkaan omat tunnit ja asiakkaan tarjoamat materiaalit tuottavat asiakkaalle oikeita kuluja. Kurssi veloittaa asiakkaalta myös osallistumismaksun. Kustannuserä Yksikköhinta Määrä Summa Projektiryhmän työ 50 e/h 1360 h e 8

9 Asiakkaan käyttämät tunnit 50 e/h 200 h e Asiakkaan materiaalikulut 5000 e Yhteensä: e Taulukko 8 - Teoreettinen kustannuslaskelma Vastaavanlainen projekti tulisi arvioiden mukaan maksamaan euroa asiakkaalle suurimpana menoeränään henkilöstökulut. Henkilöstökulut ovat laskettu kuitenkin varsin maltillisesti. Riippuen projektia tuottavan yrityksen sisäisistä kuluista ei ko. hinnalla kovin suuri voittomarginaali ole mahdollinen. 5. Työkalut ja menetelmät 5.1 Menetelmät Luku käsittelee projektissa käytetyt menetelmät, käytännöt ja työkalut. Osa menetelmistä on pakollisia kurssin puolesta ja niiden käyttö on arvostelun lähtökohtana Iteratiivinen kehittäminen Projekti tullaan kehittämään kolmessa iteraatiossa: Projektin suunnittelu (PP) - Projektin alustus ja suunnitelmat Iteraatio 1 (I1) - Tärkein toiminnallisuus ja käyttöliittymä Iteraatio 2 (I2) - Toiminnallisuuden integrointi ja projektin luovutus Jokaisen iteraation alussa karkealla tasolla suunnitellut tehtävät jaetaan pienempiin ja hallittavampiin osakokonaisuuksiin asiakkaan vaatimuksia kuunnellen. Perustana iteraation suunnitteluun on vaatimusmäärittely sekä tekniset määrittelyt joiden ajantasaisuus tarkistetaan asiakkaan kanssa ennen iteraation alkua. Iteraation aikana viikoittaisissa sykleissä (Heartbeat) vaatimukset ja tekniset määrittelyt tarkentuvat. Asiakkaalla on mahdollisuus viikoittaisen seurannan lisäksi tarkistaan jokaisen iteraation tuotokset iteraation lopulla järjestettävässä iteraatiodemossa. Tehtävä työ pyritään suunnittelemaan ja sopimaan mahdollisimman tarkasti ennen iteraation alkua, jotta iteraation aikana suuremmilta muutoksilta vältytään. Tällä osaltaan taataan kehittäjille työrauha ja edesautetaan asiakasta miettimään tarpeitaan mahdollisimman tarkasti Iteraatiosuunnittelu Ennen iteraatiota tai sen alussa pidetään asiakkaan kanssa palaveri jossa sovitaan ennalta mietittyjen kokonaisuuksien toteuttamisesta, vaatimusten priorisoinnista ja niiden toteuttamisesta sekä tulevan iteraation näkymistä. Toinen palaveri pyritään pitämään iteraation aikana jolloin projektin eteneminen ja sovitut asiat tarkistetaan. Iteraation lopullinen tilannekatsaus pidetään jokaisen iteraation lopulla iteraatiodemossa. Iteraation kuuluvien tehtävien tarkempi työmääräarvio tehdään ennen päätöstä toteutettavista komponenteista jotta asiakkaalla on mahdollisuus vaikuttaa budjetin mukaisesti iteraation 9

10 tehtäviin. Projektin budjetointi ja tehtävien ajastuksen vastuu on projektipäälliköllä. Pääarkkitehti hyväksyy iteraatiosuunnitelman työkokonaisuudet ja niiden ajastuksen Dokumentointi Projektipäällikön vastuulla on projektisuunnitelma, edistymisraportti ja iteraatiosuunnitelma. Laatupäällikkö vastaa vaatimusdokumentista ja testaukseen liittyvistä muista dokumenteista. (katselmointidokumentti, testaussuunnitelma, yms.) Pääarkkitehdin vastuulla on arkkitehtuuridokumentti. Dokumentit tuotetaan ensisijaisesti Wikiin jotta kaikilla on mahdollisuus tutustua niiden sisältöön jo kehitysvaiheessa. Lähempänä määräpäivää ne katselmoidaan ja hyväksyvän päätöksen jälkeen ne vedostetaan pdfformaattiin. Ennen julkaisua asiakas hyväksyy vielä dokumentin sisällön. Projektipäällikkö vastaa dokumenttien lopullisesta hyväksymisestä ja on vastuussa niiden jakelusta ja palauttamisesta. Dokumenteissa ja Wikissä olevat kuvat tuotetaan png-formaattiin. Dokumentin luoja on vastuussa myös siitä että viimeisin versio ja palautettu versio ovat saatavilla Wikissä. Dokumenttikohtaisesti voidaan niiden tehtäviä jakaa. Jakamisesta ja koostamisesta vastaa kokonaisuudessaan projektiryhmä Riskien hallinta Kts. luku Tuntiraportointi Jokaisen henkilökohtaiset tunnit raportoidaan Wikiin välittömästi kyseisen tehtävän suoritettua. Tuntilistaan merkitään tehtävän osa-alue ja seurannasta löytyvä tehtävä tai sen kuvaus. Viikoittainen tuntiseuranta tapahtuu projektipäällikön toimesta tiistaisin, jolloin tärkeimmät mittarit ovat seurattavissa Seuranta-sivulla. Samalta sivulta voidaan seurata myös yksittäisten tehtävien ajankäyttöä verrattuna suunniteluun. Projektipäällikkö vastaa myös tehtävien luomisesta ja päivittämisestä Ohjelmiston koon raportointi Borland Together kerää automaattista statiikkaan projektin lähdekoodista ja generoi niistä myös valmiita kaavioita. Alustavasti projektin kokoa tullaan seuraamaan koodirivien määrällä. (Yksikkö Kloc) Projektin edetessä tulee miettiä seurannan muita tarpeita ja työkalun niihin tarjoamia mahdollisuuksia. Pääarkkitehti on vastuussa tarpeellisten statiikoiden tuottamisesta ja esittelemisestä johtoryhmän viikkopalaverissa. Projektipäällikkö seuraa kehitystä ja päättää mahdollisista toimenpiteistä yhdessä projektin johtoryhmän kanssa Kommunikaatio Projektilla on käytössään useita kommunikaatiokanavia. Ensisijainen kanava projektin jäsenten kesken ovat viikoittaiset palaverit. (Projektin johtoryhmällä omansa ja pääarkkitehdin järjestämänä kehittäjille omansa) Muita kanavia ovat IRC (#softarojekti) ja sähköposti. Sähköpostin käytössä oleellista on harkita kenelle kaikille tieto on tarpeellinen ja osoittaa posti ainoastaan heille. Sähköpostissa TO-kenttään laitetaan sellaiset henkilöt joilta odotetaan toimenpiteitä. CC-kenttään laitettaville sähköposti menee tiedoksi. Projektipäälliköllä on myös käytössä 20 tekstiviestiä päivittäin ryhmän sisäiseen nopeaa reagointia tai kriittistä informaatiota varten. Kommunikaatiokanavat on koottu seuraavaan 10

11 taulukkoon odotetun vastausajan perusteella. Taulukosta voidaan myös johtaa aikavälit joiden sisällä ryhmän jäsenen tulisi olla tavoitettavissa kussakin mediassa. Kanava Odotettu vasteaika Kohderyhmä Puhelu Välitön - muutama tunti Kahdenkeskinen asia Tekstiviesti Välitön - muutama tunti Yksilö - Koko ryhmä IRC Välitön - vuorokausi Yksilö - Koko ryhmä Sähköposti Vuorokausi Yksilö - Projektin osaryhmä Wiki Yli vuorokausi Koko ryhmä Taulukko 9 - Kommunikaatiokanavat Kyseisiä kanavia voidaan käyttää kommunikointiin myös ryhmän ulkopuolelle. Asiakkaalta ja Mentorilta odotetaan myös vastaavia vasteaikoja. Mentoriin ensisijaisesti on yhteydessä projektipäällikkö ja asiakkaaseen laatu- tai projektipäällikkö Iteraatiodemo Projektipäällikkö vastaa iteraatiodemon järjestämisestä, kutsuu asianosaiset paikalle ja toimii iteraatiodemossa puheenjohtajana. Projektipäällikkö vastaa myös tilaisuudessa tarvittavasta materiaalista. Laatupäällikön vastuulla on järjestää iteraatiodemossa tuotteen esittely, varmistaa esityksen onnistuminen ja hankkia tarvittavat laitteet paikalle. Pääarkkitehti kertaa iteraation tuotannolliset asiat, tekniset yksityiskohdat ja oleelliset muutokset tuotteeseen ja arkkitehtuuriin Virheiden seuranta Testeissä löydetyistä vioista (bugeista) pidetään kirjaa. Oleellista on selvittää mistä syystä vika on päässyt syntymään ja kuinka jatkossa menetellään jotta vastaavanlaista virhettä ei pääse syntymään. Laatupäällikkö on vastuussa virhelokin ylläpidosta ja virheiden vaatimista toimenpiteistä. Loki tulee olla kaikkien saatavilla ja nähtävillä jotta siitä olisi myös hyötyä. (Esim. Wiki) Vertaistestausta suorittavan ryhmän kanssa voidaan sopia menettelyistä jos listaus on salasanan takana Versionhallinta Versionhallintaan käytetään koulun tarjoamaa (Niksula) CVS (Concurrent Versions System) työkalua. Repositorio sijaitsee koulun ympäristössä ja on täten ryhmäläisten tavoitettavissa. Ohje CVS käyttämiseksi löytyy Työkalu on valittu sen toiminnallisuuden ja tuttuuden takia. CVS käytössä noudatetaan seuraavia käytäntöjä: Vain valmiit ominaisuudet ja kääntyvä koodi päivitetään repositorioon. Muutokset kirjataan dokumentin muutoshistoriaan. 11

12 Check-in tehdään selkeän kokonaisuuden jälkeen (Usean paikan muuttaminen yhdellä commitilla ei toivottavaaa) Käytäntöjä tullaan päivittämään kun työkalu saadaan käyttöön Ohjelmointikäytännöt Yleisesti käytetään koodauskäytäntönä SUN:in esittelemää käytäntöä Koodin kommentointi Javadoc kommentointi o Jokaiselle luokalle o Jokaiselle metodille o jokaiselle tärkeälle muuttujalle Geneeristä kommentointia o Luokan alkuun luonti ja lyhyet muuttamistiedot (kuka, mitä, milloin?) o Yli viiden rivin metodiin selventäviä kommentteja mukaan Koodin ulkoasu Sisennys 4 välilyöntiä (ei tabulaattoria) Rivinleveys 80 merkkiä Vältetään yli sivun mittaisia metodeja Metodi ja muuttuja kutsuihin suorittaja eteen (this, super), ellei kyseessä ole staattinen metodi Vertaistestaus Kurssin vaatimusten perusteella tullaan suorittamaan vertaistestausta yhteistyössä toisen kurssia suorittavan projektiryhmän kanssa. Asiakkaan vaatimuksena on että lähdekoodia ei näytetä projektin ulkopuolelle. Tämä otetaan huomioon testattaessa ainoastaan valmiita paketteja. Toisen rajoitteet testaukselle asettaa testauksen vaatima laitteisto. Riippuen ryhmien sopimista menettelyistä, vertaistestaukseen tullaan sopimaan tietty määrä resursseja kummastakin ryhmästä. Vertaistestaus suunnitellaan vertaisryhmän projektin ominaisuuksista riippuen. Vertaistestauksesta lisää laadunvarmistusdokumentissa Vaatimusten hallinta Katso Vaatimustenhallintadokumentti SEPA - Heuristinen arviointi Heuristinen arviointi on tuotteen tai käyttöliittymän arviointia ilman käyttäjiä tiettyihin käytettävyyssääntöihin vertaamalla. Heuristinen arvio tulisi tehdä 3-5 asiantuntijan voimin. Heuristisella arvioinnilla haetaan lopputuotteen hyvää käytettävyyttä. Projektissa menetelmää tullaan käyttämään ainakin ensimmäisen iteraation alussa prototyypin arviointiin ja parantamiseen sekä lopussa edesauttamaan käyttöliittymän kehittämisessä. 12

13 SEPA - Design Patterns Suunnittelumallit (Design Patterns) ovat ohjelmiston rakenteen hyväksi havaittuja yleisiä malleja. Suunnittelumallit toimivat arkkitehdin apuna suunnittelutyössä. SEPA tulee käsittelemään ns. Gang-of-Four suunnittelumalleja joita ovat mm. adapter, factory, facade, jne SEPA - Static Methods Static methods tarkoitetaan ohjelmiston (esim. lähdekoodin) analysointia ilman että sitä ajetaan. Static methods analyysi voi olla mm. koodikatselmuksien suorittamista. Tarkoituksena on mitata, analysoida ja parantaa ohjelmiston rakennetta sekä löytää siinä ilmeneviä virheitä. Projektin kontekstissa ohjelmiston kriittisiä osia tullaan katselmoimaan muiden tuotosten ohella SEPA Refactoring Refactoring tarkoittaa ohjelmakoodin rakenteen muuttamista ilman sen toiminnallisuuden muuttamista. Tällä tavoitellaan selkeämpää, luettavampaa ja ylläpidettävämpää koodia lyhyemmässä ja alkuperäistä paremmassa muodossa. Projektin kannalta nämä ominaisuudet ovat varsin tärkeät asiakkaan jatkokehityksen kannalta. Tarkoituksena on suorittaa refactorointia jatkuvasti kehityksen aikana. Esimerkiksi hyvä käytäntö tarkistaa refactorointitarve on jokaisen metodin kirjoittamisen jälkeen ja työskentelyjakson päätyttyä. Näin koodin toiminnallisuutta ei tarvitse välttämättä kerrata. Yksinkertaisimmillaan refactoring voi olla esim. koodin muotoilu konventioiden mukaiseksi metodin kirjoittamisen jälkeen. 5.3 Työkalut Nimi Versio Lähde Tarkoitus Apache Ant Kääntäjä CVS Versionhallinta Jetty Www-palvelin Log4j Ohjelman toiminnan raportoija JUnit Testaustyökalu MagicDraw UML-työkalu Eclipse Koodin kehitystyökalu javadoc Kommentointi Wiki Tiedon välittäminen ja ylläpitäminen Irc Kommunikointi Cobertura Testien kattavuuden mittaaja 13

14 Borland Together Architect Asennusohjeet kurssin kotisivuilla Tools-valikon alla. products/together/index.html Hibernate Tietokannan käsittely Quartz Skeduloija Spring Framework 5.4 Standardit UI Framework Taulukko 10 - Käytetyt työkalut Standardeja tullaan päivittämään projektin kuluessa. Tähän mennessä mainittavan arvoiset käytettävät standardit tai protokollat ovat: TCS (Tetra Connectivity Server) LIP (Location Information Protocol) o Paikkatiedon välitys Tetra-verkossa HTML 4.01 (HyperText Markup Language) o Tai vaihtoehtoisesti XHTML 1.0 Säädökset palovaroittimien valvomiselle 6. Jaksotus Projekti on jaettu kolmeen iteraatioon. Seuraavassa luvussa kuvataan iteraatioiden tavoitteet, tuotokset, tehtävät sekä niiden työarviot ja tärkeät päivämäärät iteraation aikana. 6.1 Aikataulu Projektin aikataulun kuvaaja löytyy liitteestä 2. Päivä Kello Tapahtuma Selitys Osallistujat Viikkopalaveri Johtoryhmä Luento Software process, project planning Palautus Iteraatiosuunnitelma Luento Requirements management Vaatimusmäärittely Ensimmäinen versio valmis Luento Borland's development tools Arkkitehtuuri Iteraation arkkitehtuuri valmis Palautus Projektisuunnitelma, 14

15 Vaatimusdokumentti, Edistymisraportti Luento Quality assurance Iteraatiodemo Johtoryhmä, Mentor, Asiakas Taulukko 11 - Projektin Suunnittelu ( ) Päivä Kello Tapahtuma Selitys Osallistujat Project Kick-off Projektiryhmä, Asiakas, Mentor Asiakaspalaveri Iteraatiosuunnitelman palautus Mentor-tapaaminen Iteraation suunnittelu Iteraatio- ja QAsuunnitelma Johtoryhmä Kattilamäki, Rönkkö Johtoryhmä Iteraation toiminnallisuus valmis Palautus SEPA-päiväkirjat Palautus Kts. kurssin sivut Iteraatiodemo Johtoryhmä, asiakas, Menor Joululoma Päätetään muöhemmin Kaikki Taulukko 12 - Ensimmäinen Iteraatio ( ) Päivä Kello Tapahtuma Selitys Osallistujat Palautus Iteraatio- ja QAsuunnitelma Kattilamäki, Rönkkö Iteraatiodemo Järjestelmän toiminnallisuus valmis Vertaistestaukseen luovutus Edistymisen seuraus Lopullinen järjestelmä ja ohjeet Vertaistestauksen palaute Palaute vertaisryhmälle Rönkkö Rönkkö Dokumenttien palautus Johtoryhmä 15

16 Iteraatiodemot Project Close-Out Party Mentor, Asiakas, Projektiryhmä Projektiryhmä, Asiakas, Mentor 6.2 Projektisuunnnittelu Projektin suunnittelu (PP) Taulukko 13 - Toinen Iteraatio ( ) Projektin suunnitteluvaiheen tavoitteena on Aihealueen ymmärtäminen Asiakaskontaktin luominen Projektin alkuun saattaminen Alustava arkkitehtuuri Vaatimusmäärittely Laadunvarmistuksen suunnittelu Projektin suunnitteluvaiheen tuotokset ja työarvio Suunnittelu (50 h) o Projektisuunnitelma o Arkkitehtuuri Dokumentointi (64,8 h) o Iteraatiosuunnitelma (20 h) o Vaatimusdokumentti (5,8 h) o Edistymisraportti (7 h) o Projektisuunnitelma (10 h) o Arkkitehtuuri (3 h) o Vaatimusmäärittely (19 h) Infrastruktuuri (4,4 h) o Wikin pystytys (3 h) o CVS pystytys (1,4 h) Luento (40,8 h) Palaveri (40 h) o Viikkopalaverit (12 h) o Asiakaspalaveri (9 h) o Mentor-tapaaminen (10 h) Hallinnointi (20 h) o Tuntiraportointi (3 h) o Aiheen valmistelu (6 h) o Palaverien valmistelu (3,5 h) o Projektinhallinta (7,5 h) Opiskelu (20 h) 16

17 o Kertaus (1 h) o Laatuasiat (1,5 h) o Käytettävät työkalut (16 h) o Muu (1,5) Kommunikaatio (5 h) Muu (5 h) Ensimmäinen iteraatio Projektin ensimmäisen iteraation tavoitteena on Tärkeimpien toiminnallisuuksien toteuttaminen Arkkitehtuurin ja vaatimusten tarkentaminen Käyttöliittymän kehittäminen, testaus ja arviointi Kattava testaus ja käytäntöjen juurruttaminen Projektin osa-alueille varattu aika nähdään taulukosta 5. Tarkempi tehtäväkuvaus ja aikataulu ensimmäisen ja toisen iteraation suunnitelmasta Toinen iteraatio Projektin toisen iteraation tavoitteena on Laadukkaan lopputuotteen toimittaminen asiakkaalle Projektin oppien kokoaminen Toiminnallisuuksien integrointi Mahdollisen jatkokehityksen edistäminen (dokumentaatio, käyttöohje) Kurssin tavoitteellinen suorittaminen 7. Riskienhallinta 7.1 Prosessi Oleellisena osana projektin seurantaa on riskien hallinta. Päävastuu riskien hallinnasta ja seurannasta kuuluu projektipäällikölle. Riskejä seurataan viikoittain johtoryhmän viikkopalaverissa ja projektipäällikkö päättää seuraavista toimenpiteistä. Jokaisen projektiin osallistuvan henkilön velvollisuus on ilmoittaa havaitsemastaan uudesta riskistä viipymättä projektipäällikölle. Näin riski saadaan kartoitettua, siihen voidaan valmistautua ja vaikutusta minimoida. Oleellista riskien hallinnassa on tunnistaa riskit, arvioida niiden vaikutus sekä hallita ja tarkkailla niitä. Riskin alttius riippuu sen todennäköisyydestä ja vaikutuksesta. Näiden määreiden korkeat arvot tietyssä riskissä on kirjattu kuhunkin riskiin. 17

18 Kuva 3 - Riskienhallintaprosessi Projektin aikana on mahdollista käydä toteen myös projektista riippumattomia riskejä joihin ei voida varautua tai se ei ole järkevää. (esim. poikkeustila, luonnonmullistus) Kyseisenlaisia riskejä ei ole listattu riskilokiin. 7.2 Riskikategoriat Riskin poistuttua riski poistetaan listalta, uudet riskit kirjataan. K = Kriittinen, T = Todennäköinen TOP 5 riskit ID Toimenpiteet poistamiseksi listalta Vastuu S1 Varmistetaan projektiryhmän osaamistaso. Järjestetään tarvittaessa Laakso koulutusta T1 Valittavat teknologiat tutkitaan perusteellisesti ja hyväksytetään ne myös asiakkaalla S3 Varmistetaan että jokainen on tietoinen vaaditusta työmäärästä ja on valmis varaamaan sen J2 Tehdään verkolle rasitustestit Rönkkö Kattilamäki Rönkkö 18

19 L3 Huolehditaan että kaikki ymmärtävät vastuunsa ja noudattavat sitä Kattilamäki Asiakas ID Riski Vaikutus Korjaavat toimenpiteet A1 K Asiakkaalta ei saada selkeitä, tai edes selkeähköjä, vaatimuksia Projektia on vaikea saada onnistumaan Parannetaan kommunikaatiota ja vaatimusten määrittelyprosessia Vastuuhenkilö Rönkkö A2 Asiakas ei ymmärrä projektin prosessia ja siihen liittyviä asioita riittävällä tasolla Asiakkaan ja projektiryhmän näkemys projektista ristiriitainen Lisäämällä kommunikaatiota ja sen laatua yhtenäistetään näkemykset Rönkkö Teknologia ID Riski Vaikutus Korjaavat toimenpiteet T1 Teknologiavalinnat Teknologioiden Soveltuvat eivät sovellu muuttaminen syö teknologiat valitaan projektiin resursseja projektin alussa T2 K Verkko ei kestä vaadittua kuormitusta Tuotteen jatkokehitys ei mielekästä tarkasti Hyödynnetään kertynyt kokemus muuten Vastuuhenkilö Laakso Rönkkö Sidosryhmä ID Riski Vaikutus Korjaavat toimenpiteet S1 K Sidosryhmillä ei ole tarpeeksi tietoa järjestelmän rakentamiseen Järjestelmä ei vastaa odotuksia Taataan kaikkien osapuolien näkemys projektiin Vastuuhenkilö Kattilamäki 19

20 S2 Projektiryhmästä keskeyttää useampi henkilö Työpanoksen ja tietotaidon menetys Tehtävien jakaminen ja projektin scopen muutos vastaamaan resursseja. Kattilamäki S3 T Projektiin osallistujilla ei ole tarpeeksi aikaa projektille Projekti ei pysy aikataulussa eikä määriteltyjä tavoitteita saavuteta Projektin edistymistä ja osallistujien ajankäyttöä on seurattava tarkasti. Kriittisessä tilanteessa resurssien käyttö suunniteltava uudelleen Kattilamäki Projektinhallinta ID Riski Vaikutus Korjaavat toimenpiteet P1 Arkkitehtuurin alkuun Arkkitehtuuri Toteutetaan saattamisen myöhästyy arkkitehtuuria sen kannalta tärkeiden hetkisten vaatimusten vaatimusten etsintä perusteella ja tehdään kestää liian pitkään siitä mahdollisimman helposti muutettava P2 K Alihankkija ei saa ajoissa toimitettua tarvittavia komponentteja P3 T Vaatimukset ovat puutteelliset P4 T Projekti ei pysy budjetissa P5 Kriittinen osakokonaisuus ylittää budjetin Suunnittelu ja toteutus vaikeutuvat ja myöhästyvät Lopputuote ei vastaa asiakkaan tarpeita Ei pystytä vastaamaan asiakkaan vaatimuksiin Projektia ei pystytä jatkamaan suunnitellusti Toteutetaan mahdollisimman joustavia komponentteja ja rajapintoja Tarpeeksi lyhyt palautesykli, prototyyppien käyttö ja läpinäkyvä prosessi Vaatimusten priorisointi ja karsiminen Projektin uudelleen aikatauluttaminen ja korvaavien toimenpiteiden suorittaminen Vastuuhenkilö Laakso Laakso Rönkkö Kattilamäki Kattilamäki 20

21 7.3.5 Järjestelmä ID Riski Vaikutus Korjaavat toimenpiteet J1 K Projektin lopputuote ei skaalaudu jatkotuotantoon Projektin tarkoituksen menettäminen enne toista iteraatiota Toisen iteraation työn varmistaminen Vastuuhenkilö Kattilamäki J2 K Virve ei sovellu projektin vaatimaan toimintaan Ei tarkoitusta jatkotuottaa projektia Varmistetaan Virven toiminnallisuus projektin kontekstissa Rönkkö Kurssi ID Riski Vaikutus Korjaavat toimenpiteet K1 Johtoryhmä ei Vaikutus näkyy Ylimääräisen ajan opiskelullaan pysty projektin käyttäminen paikkaamaan lopputuotteessa ja opiskeluun ja osaamisessaan arvostelussa neuvojen olevia puutteita hankkimiseen K2 T Projektin laatu ei vastaa ryhmän tavoitteita Motivaatio projektiin laskee Tarkistetaan ryhmän motivaatiotaso ja tavoitteet ja johdetaan niistä projektin tuotteiden laatutaso Vastuuhenkilö Johtoryhmä Kattilamäki Laillinen / Kaupallinen ID Riski Vaikutus Korjaavat toimenpiteet Vastuuhenkilö L1 K Projektista vuotaa kriittistä tietoa ulos Asiakkaalle huono maine Dokumentit tarkistetaan ennen julkaisua ja rajataan kriittinen informaatio ulkopuolisilta (NDA) Kattilamäki 21

22 L2 Asiakkaan tuotteet sekoitetaan projektin tuotoksiin Asiakkaan myynnin lasku Projektin selkeä nimeämiskäytäntö ja huhujen rajoittaminen Projektiryhmä L3 K Projektiryhmä rikkoo NDA:ta Mahdollinen haitta asiakkaalle ja rikkovan osapuolen vastuu Varmistetaan että kaikille osapuolille sopimuksen alainen aineisto on selvä ja rikkomustapauksissa neuvotellaan. TEK:n jäsenillä mahdollisuus asianajajaan. Projektiryhmä 8. Lähteet 1. "Software Project Management", Hughes, B. Cotterell, M. McGraw-Hill 2002, ISBN X 2. "Projektihallinnan käsikirja", Pelin, R. 1. painos Projektijohtaminen Oy "Software Engineering 7", Sommerville, I. ISBN "Object-Oriented and Classical Software Engineering", Schach, S. McGraw-Hill "An introduction to SEMS Approach", Rautiainen, R. Vähäniitty, J. 22

23 23 T Ohjelmistoprojekti I

24 24 T Ohjelmistoprojekti I