Projektisuunnitelma v. 3.1 Päivitetty 11.12.2000 klo 19:30
Jussi Isotupa 2 (30) Dokumentin versiohistoria Versio Päivämäärä Muutoksen tekijä Selite 3.1 11.12.2000 Jussi Isotupa Päivitetty T3-vaiheen tehtävät 3.0 6.12.2000 Jussi Isotupa Tarkennettu käytettyjä työkaluja testipalvelimen osalta sekä käytettävää code conventionia. Lisätty liitteeksi muistilista T2-palautusta varten. Vaihdettu työkaluista käytettävä tietokantapalvelin ja lisätty maininta hakemistopalveluista. 2.2 7.11.2000 Jussi Isotupa Lisätty T2-vaiheen aikana toteutettavat tuotokset ja kappale vaatimusten hallinnasta. Muutettu kooditarkastusten (8.7) määrittelyä, käytettävää palvelinalustaa sekä ulkoasua. Poistettu laatupäällikön tehtävistä koodin hyväksyminen. Selvennetty projektin tavoitetta. 2.1 2.11.2000 Jussi Isotupa Lisätty maininta JUnit-ohjelman käyttämisestä moduulitestaukseen. 2.0 26.10.2000 Jussi Isotupa Lisätty versiohistoria, versionumerointi ja kustannusarvio. Korjattu sisällysluettelosta turhat pois. 1.0 17.10.2000 Jussi Isotupa Projektisuunnitelman ensimmäinen versio valmis. PROJEKTISUUNNITELMA 2
Jussi Isotupa 3 (30) Projektiryhmällä tarkoitetaan opiskelijoiden muodostamaa työryhmää, jonka vastuulla on projektin toteutus. Asiakkaalla tarkoitetaan projektin lopputuotteen vastaanottajaa, eli A-Ware Oy:tä. Tiivistelmä Asiakkaan projektit koostuvat usein palvelinpuolen sovelluksista, jotka toteutetaan räätälöidysti A-Ware Oy:n asiakkaan tarpeisiin. Sovellukset julkistavat usein palveluita Internetiin, Intranetiin tai Extranetiin. Näillä sovelluksilla on lähes aina liityntöjä tietokantoihin, tapahtumankäsittelyjärjestelmiin tai muihin olemassaoleviin tietovarastoihin ja järjestelmiin. Johtuen järjestelmien ja käyttäjätietojen eroista projektien väleillä, on perinteisesti käyttäjien ja käyttöoikeuksien hallinta jouduttu toteuttamaan projektikohtaisesti. Projektin tavoitteena on kehittää sovelluskehikko, joka tarjoaa rajapintoja ja valmiiksi toteutettuja toimintoja käyttäjien autentikointiin sekä käyttäjätietojen ja käyttöoikeuksien hallintaan. Kehitettävän sovelluskehikon tulee toimia modulaarisena ja laajennettavana, jolloin ei sitouduta tiettyihin tietolähteisiin tai tietoihin. Tämä dokumentti sisältää projektisuunnitelman, joka kuvaa projektiryhmän käytännöt, resurssit, käytettävät menetelmät, aikataulun sekä projektin tavoitteet ja sen riskit. PROJEKTISUUNNITELMA 3
Jussi Isotupa 4 (30) Sisällysluettelo Tiivistelmä... 3 1. Johdanto... 5 2. Termit ja määritelmät... 7 3. Asiakkaan nykyinen ratkaisu... 8 4. Projektin toteutusperusteet... 9 5. Projektin organisaatio... 10 6. Projektin tavoitteet ja päättäminen... 15 7. Projektin resurssit... 18 8. Projektissa käytettävät menetelmät ja työkalut... 20 9. Projektin ositus, vaiheistus ja resurssointi... 23 10. Seuranta ja ohjaus... 25 11. Standardit, direktiivit ja määräykset... 26 12. Riskienhallintasuunnitelma... 27 13. Projektiryhmän sisäinen koulutussuunnitelma... 28 Lähdeluettelo... 29 Liiteluettelo... 30 PROJEKTISUUNNITELMA 4
Jussi Isotupa 5 (30) 1. Johdanto 1.1. Projektin tarkoitus ja kattavuus Ryhmä suunnittelee ja toteuttaa geneerisen sovelluskehikon, joka tarjoaa palveluita käyttäjien autentikointiin ja käyttöoikeuksien hallintaan hajautetuissa ympäristöissä. Kehikon ajatus on tarjota sovelluskehitystä helpottava ja nopeuttava abstraktio alla oleville käyttäjätietolähteille siten, että samoja komponentteja voidaan käyttää riippumatta allaolevasta käyttäjätietovarastosta (esim. LDAP, tietokannat jne.). Arkkitehtuuriin tulee voida liittää rajapintoja mahdollisesti myös myöhemmin lisättäviin käyttäjätietovarastoihin. Sovelluskehikon itse toteutus ei ole ensisijaisen tärkeä, vaan malli siitä, kuinka käyttäjätiedoista muodostuvan kokonaisuuden hallinta on helppoa ja järkevää hajautetussa ympäristöissä. Ryhmän mahdollisesti löytämä ratkaisu toteutetaan Javalla ja mallia pilotoidaan esimerkkisovelluksella. Esimerkkisovelluksena käytetään yksinkertaista Webiin toteutettavaa projektin tuntiseuranta sovellusta. Myös tämä toteutetaan Java-pohjaisesti. 1.2. Asiakas Projektin asiakas on A-Ware Oy, joka on Espoossa sijaitseva itsenäinen internettalouden ratkaisuja kehittävä ohjelmisto- ja asiantuntijayritys, jonka asiakaskunta koostuu muutamasta valitusta, oman alansa johtavasta kansainvälisesti toimivasta telekommunikaatio-, media-, pankki-, rahoitus- ja vakuutusalan yrityksestä. A- Ware Oy on uuden teknologian luotettava kumppani ja sen menestys perustuu vankkaan osaamiseen ja asiantuntemukseen niin Java-/internet- ja olioteknologioiden kuin myös tietoturvan alueella. A-Ware Oy tekee yhteistyötä muun muassa sellaisten merkittävien teknologiatoimittajien kanssa kuten BEA Systems, IBM, Oracle ja Sun Microsystems. A-Ware Oy:llä on henkilökuntaa kirjoittamisen hetkellä noin 20 työntekijää, ja uuden yksikön käynnistyttyä vuoden vaihteessa tulee olemaan noin 30 työntekijää. [1] Asiakkaan yhteyshenkilönä toimii toimitusjohtaja Nina Kesälä ja ohjaajana Arto Laurila. 1.3. Oikeudet työn tuloksiin Oikeudet lähdekoodiin jäävät asiakkaalle. Projektin pääasiallinen tarkoitus on kuitenkin löytää malli käyttäjätietojen käyttöön, eikä asiakas puutu asiaan, jos projektiryhmän jäsenet hyödyntävät löydettyä mallia ja projektin aikana saavutettua tietoutta. PROJEKTISUUNNITELMA 5
Jussi Isotupa 6 (30) Projektiryhmän tuottama dokumentaatio on julkista ja sen tekijänoikeudet kuuluvat asiakkaalle. Jos asiakas yksipuolisesti haluaa keskeyttää projektin, voi projektiryhmä jatkaa projektia. Tällöin asiakas menettää oikeutensa projektin tuotoksiin ja kaikki oikeudet siirtyvät projektiryhmälle. 1.4. Projektisuunnitelman rakenne Projektisuunnitelman 1. luku sisältää lyhyen kuvauksen asiakkaasta, toteutettavasta sovelluskehikosta ja projektin luonteesta. Luku sisältää myös ohjeet projektisuunnitelman ylläpitoon. 2. luvussa käydään läpi projektisuunnitelmassa käytetyt termit ja lyhenteet. Kolmas ja neljäs luku kuvaavat asiakkaan tämän hetkisen ratkaisun ja motiivin sovelluskehikon kehittelylle, sekä projektista koituvat kustannukset ja haitat asiakkaalle. Viidennessä luvussa esitellään projektiorganisaatio, projektiryhmän jäsenet sekä sidosryhmät intresseineen. Kuudennessa luvussa esitellään projektin tavoitteet eri sidosryhmien näkökulmista katsoen ja seitsämäs luku listaa projektin käytettävissä olevat resurssit. Kahdeksas luku käy läpi projektiryhmän käyttämät menetelmät ja työkalut, joilla sovelluskehikko suunnitellaan ja toteuteaan. Yhdeksännessä luvussa projekti ositetaan ja osat esitellään. Lisäksi luvussa käydään läpi käytettävät resurssit vaiheittain, ja luvussa kymmenen käsitellään projektin vaiheiden seurantaan ja ohjaukseen käytettävät menetelmät. Luvussa 11 käydään läpi projektia koskevat direktiivit ja määräykset sekä projektin noudattamat standardit. Luku 12 esittelee projektiin kohdistuvat riskit ja menetelmät niiden välttämiseksi ja vahinkojen korjaamiseksi. Kolmastoista luku käsittelee ryhmän sisäisen koulutussuunnitelman. Projektiryhmä ei järjestä koulutusta asiakkaalle. 1.5. Projektisuunnitelman päivittäminen Projektisuunnitelma pidetään jatkuvasti projektin aikana ajantasalla. Projektisuunnitelma toimii eräänlaisena sopimuksena asiakkaan ja projektiryhmän välillä sekä tiedotuskanavana projektin käytännöistä. PROJEKTISUUNNITELMA 6
Jussi Isotupa 7 (30) 2. Termit ja määritelmät asiakas A-Ware Oy. Asiakkaan ollessa yritys, yrityksen edustajana toimii toimitusjohtaja Nina Kesälä. EJB Enterprise Java Beans, Javan komponenttiarkkitehtuuri. [2] katselmus projektin vaiheen loppuessa pidettävä tilaisuus, johon osallistuu asiakkaan edustaja, kurssin assistentti ja projektiryhmä. J2EE Java 2 Enterprise Edition, sovelluskehitysrajapinta Javalla toteutettuihin hajautettuihin sovelluksiin. [3] projektiryhmä opiskelijoiden muodostama työryhmä, katso projektiryhmän kokoonpano ohjaaja Ohjaa projektiryhmän työskentelyä ja auttaa projektiryhmää asiakkaan näkökulmasta. tarkastus projektiryhmän osan sisäinen tarkastus, jossa projektiryhmän jäsenet tarkastavat keskenään omaa työtään laadun varmistamiseksi. tilaaja Asiakkaan edustaja, joka on tilannut tuotteen. sovelluskehikko toteutettava rajapinnoista rakentuva malli, jolla mallinnetaan käyttäjätietoja ja käyttöoikeuksia. PROJEKTISUUNNITELMA 7
Jussi Isotupa 8 (30) 3. Asiakkaan nykyinen ratkaisu A-Ware Oy toteuttaa asiakkailleen räätälöityjä sovellusratkaisuja asiakkaiden tarpeisiin. Sovellukset lähes aina sisältävät jonkinasteista käyttäjän tunnistamista ja profilointia. Tällä hetkellä käyttäjien hallinta ja oikeuksien valvontaan ei ole yleiskäyttöistä ratkaisua, ja suuri osa käyttäjäinformaatioon liittyvästä toiminnallisuudesta joudutaan rakentamaan tai sovittamaan projektikohtaisesti. Tämä on aikaa ja resursseja vievä prosessi, jonka toistaminen jokaisessa projektissa on turhaa. Lisäksi tämä johtaa siihen, että ratkaisussa helposti sitoudutaan voimakkaasti johonkin suunnittelun ja toteutuksen aikana käytössä olleeseen teknologiaan, jolloin ratkaisu on riippuvainen tästä teknologiasta. Esimerkkinä voisi olla sitoutuminen johonkin tiettyyn tietokantaan, esimerkiksi DB2:en, jolloin sovelluksen käyttämän tietokannan vaihtaminen esimerkiksi Oracleen voi aiheuttaa mittavia muutoksia sovelluksessa. PROJEKTISUUNNITELMA 8
Jussi Isotupa 9 (30) 4. Projektin toteutusperusteet Projektista ei aiheudu asiakkaalle suoranaisia kustannuksia projektin vuoksi poislukien kurssin ilmoittautumismaksu. Asiakas antaa projektin toteuttamista varten projektiryhmälle mahdollisuuden erinäisten työkalujen käyttöön. Projektia varten ei hankita uutta laitteistoa tai ohjelmistoa. Projektiryhmään kuuluu kaksi asiakkaan työntekijää, joiden käyttämä aika projektiin on poissa muusta työnteosta asiakkaalle. Lisäksi ohjaaja sitoutuu käyttämään aikaansa projektin katselmuksiin ja projektiryhmän ohjaukseen ja neuvomiseen. Asiakkaan tavoitteena on tuoda lisää joustavuutta sovelluskehitykseen ja saavuttaa kustannussäästöjä helpottamalla sovelluskehitystä jatkossa sekä mahdollisia muutoksia sovelluskehikon pohjalta toteutettuihin sovelluksiin. PROJEKTISUUNNITELMA 9
Jussi Isotupa 10 (30) 5. Projektin organisaatio Nina Kesälä Asiakas A-Ware Oy Kristian Rautiainen Kurssiassistentti Arto Laurila TKK Ohjaaja A-Ware Oy arvioi Projektiryhmä Tomas Björnfot Projektipäällikkö Projektiryhmä Jussi Isotupa Tietolähdepäällikkö Projektiryhmä Timo Lämsä Laatupäällikkö Projektiryhmä Janne Kankaanpää Dokumentointipäällikkö Projektiryhmä Mickey Shroff Käytettävyyspäällikkö Projektiryhmä Opponenttiryhmä TKK Mikko Viljainen Testauspäällikkö Projektiryhmä 5.1. Projektiryhmä Jotta yksittäiset projektiryhmän jäsenet eivät olisi korvaamattomia, on jäsenille sovittu varahenkilöt. Varahenkilöt voivat hoitaa ryhmän jäsenen tehtäviä sairauden tai muun työkyvyttömyyden sattuessa. Varahenkilöiden tulee olla perillä tuurattavansa tehtävistä ja asioista tasolla, että korvaaminen todella on mahdollista. Tomas Björnfot, Projektipäällikkö Tomas vastaa projektiryhmän johtamisesta sekä A-Waren työntekijänä yhteydenpidosta asiakkaaseen. Tomaksen varahenkilönä toimii Jussi Isotupa. Puhelin: 040-584 4830 PROJEKTISUUNNITELMA 10
Jussi Isotupa 11 (30) E-mail: tbjornfo@cc.hut.fi, tomas.bjornfot@aware.fi Kiinnostus- ja osaamisalueet: Java Server Programming Opiskelu- ja työkokemus:?? 5. vuosikurssi TKK:lla tietotekniikan osastolla?? 1,5v. Hairstore Oy, ohjelmoija, Java -pohjaisen verkkokaupan suunnittelu ja toteutus, sekalaista Windows-ohjelmointia, Linux-ylläpitoa?? 0,5v. A-Ware Oy, Java programmer (työsuhde voimassa), hajautettujen Java-sovellusten suunnittelua ja toteutusta, WAP?? Henkilökohtainen kiinnostus projektia kohtaan työnantajan kautta Jussi-Pekka Isotupa, tietolähdepäällikkö Jussi vastaa tietolähdemodulien suunnittelusta ja toteutuksesta. Lisäksi hän hoitaa projektin ohjausta Tomaksen varahenkilönä. Puhelin: 040-587 0686 E-mail: jisotupa@cc.hut.fi, jussi@weppihiiri.com Kiinnostus- ja osaamisalueet: Windows DNA arkkitehtuuri, hajautetut sovellukset, tietokannat Opiskelu- ja työkokemus:?? 5. vuosikurssi TKK:lla konetekniikan osastolla.?? 1,5v. WM-Data Faci Oy, asentaja, laitteiston ja ohjelmistojen esiasennukset, turvamerkinnät?? 2v. Tielaitoksen tuotanto, tiedonhallinta, suunnittelija, Intranetsovelluskehitys käyttäen Microsoftin tuotteita, asiakas/alihankkija/kilpailija rekisterin suunnittelu ja toteutus, tarjous- ja sopimusrekisterin suunnittelu ja toteutus?? 0,5v. Weppihiiri Oy, Tekninen johtaja (työsuhde voimassa), WWWsovelluskehitys Microsoft-tuotteilla, businesslogiikka ja tietokannat Janne Kankaanpää, dokumentointipäällikkö Janne vastaa dokumenttien laadusta, yhtenäisyydestä ja versionhallinnasta. Jannen varahenkilönä toimii Mikko Viljainen. Puhelin: 050-548 0899 E-mail: jjkankaa@cc.hut.fi, janne.kankaanpaa@aware.fi Kiinnostus- ja osaamisalueet: Java programming Opiskelu- ja työkokemus:?? 2,5 vuotta Vaasan yliopistossa tietotekniikkaa?? vuosikurssi TKK:lla?? 0,5v. ICL, Vaasa, harjoittelija, sekalaista WWW-ohjelmointia?? 0,5v. Vaasan yliopisto, assistentti, tietorakenteet ja olio-ohjelmointi PROJEKTISUUNNITELMA 11
Jussi Isotupa 12 (30)?? 0,5v. A-Ware Oy, Java programmer (työsuhde voimassa), hajautettujen sovellusten toteutus Java-tuotteilla Timo Lämsä, Laatupäällikkö Timo vastaa sovelluskehikon laadusta ja pyrkii luomaan systemaattista toimintatapaa ryhmän sisälle. Timon varahenkilönä toimii Mickey Shroff. Puhelin: 040-501 6084 E-mail: tlamsa@cc.hut.fi, timo@weppihiiri.com Kiinnostus- ja osaamisalueet: tietokannat, komponenttiohjelmointi, www-sovellusten ohjelmointi, MS:n työkalut edellämainittuissa Opiskelu- ja työkokemus:?? 5. vuosikurssi TKK:lla tietotekniikan osastolla?? 1½v. Tielaitoksen tuotanto, Intranet-sovellukset?? 1v. Hewlett-Packard, Intranet-sovellukset?? ½v. Weppihiiri Oy, Toimitusjohtaja (työsuhde voimassa)?? 2kk Kirahvi-domainit Oy, Toimitusjohtaja (työsuhde voimassa) Mickey Shroff, Käytettävyyspäällikkö Mickey vastaa siitä, että sovelluskehikko on käyttökelpoinen, helppo ja mukava. Sovelluskehikon tarkoituksena kuitenkin on helpottaa sovelluskehitystä eikä tehdä siitä monimutkaista ja vaikeaa. Mickeyn varahenkilönä toimii Timo Lämsä. Puhelin: 050-302 7187 E-mail: mshroff@cc.hut.fi Kiinnostus- ja osaamisalueet: c, c++, java, sulautetut järjestelmät, reaaliaikakäyttöjärjestelmät, tietokannat, WWW-sovellukset ja tietoturvallisuus Opiskelu- ja työkokemus:?? Aikaisempia opintoja Vaasassa?? vuosikurssi TKK:lla tietotekniikan osastolla?? Työkokemusta c:n, c++:n, sulautettujen järjestelmien, reaaliaikakäyttöjärjestelmät, ja salausalgoritmien parissa. Mikko Viljainen, Testauspäällikkö Testauksen erikoismiehenä Mikko suunnittelee ja osittain toteuttaa järjestelmän kuormitus- ja toiminnallisuustestauksen, sekä ohjaa moduulitestausta. Mikon varahenkilönä toimii Janne Kankaanpää. Puhelin: 040-747 0222 E-mail: mviljain@cc.hut.fi Kiinnostus- ja osaamisalueet: Testaus PROJEKTISUUNNITELMA 12
Jussi Isotupa 13 (30) Opiskelu- ja työkokemus:?? 5. vuosikurssi TKK:lla konetekniikan osastolla 5.2. Sidosryhmät 5.2.1. Asiakas, A-Ware Oy Nina Kesälä, Asiakas E-mail: nina.kesala@aware.fi Puhelin: 09-4520 8822 GSM: 050-380 0044 Arto Laurila, Ohjaaja E-mail: arto.laurila@aware.fi Puhelin: 09-4530 8816 GSM: 050-548 0894 Sovelluskehikon käyttäjät Sovelluskehikon käyttäjäkuntaa tulevat olemaan asiakkaan ohjelmoijat, sekä mahdollisesti myös asiakkaan asiakkaat. 5.2.2. TKK, Ohjelmatyökurssin edustajat Kristian Rautiainen, Projektiryhmän kurssiassistentti Kristian toimii ohjelmatyökurssin edustajana ja ohjaajana sekä osallistuu katselmuksiin. E-mail: Kristian.Rautiainen@hut.fi WWW: http://mordor.cs.hut.fi/~kqr/ GSM: 050-501 4099 Puhelin: 451 5063 Fax: 451 4958 5.2.3. Opponenttiryhmä Kurssin muista projektiryhmistä yksi valitaan projektiryhmän opponenttiryhmäksi. n opponenttiryhmä on Hayabusa. Opponenttiryhmät arvioivat toistensa työtä. PROJEKTISUUNNITELMA 13
Jussi Isotupa 14 (30) 5.2.4. Weppihiiri Oy Projektiryhmään kuuluu Weppihiiri Oy:n työntekijöitä. Vaikka Weppihiiri ei yrityksenä ole mukana projektissa, voi Weppihiiri Oy luovuttaa projektiryhmän käyttöön palvelintiloja sekä ohjelmistoja. PROJEKTISUUNNITELMA 14
Jussi Isotupa 15 (30) 6. Projektin tavoitteet ja päättäminen 6.1. Projektiryhmän tavoitteet 1. Projektiryhmän ensisijainen tavoite on hyvän projektityöskentelyn opetteleminen. Tämä sisältää käytetyt menetelmät ja työkalut. Tavoitteeseen kuuluu myös se, että projektiryhmä hahmottaa kaikkien osapuolien tasaisen työpanoksen merkityksen. 2. Tyytyväinen asiakas. Tämä saavutetaan hyvällä lopputuotteella, joka taas on seurausta hyvästä suunnittelusta, dokumentoinnista ja laadunvalvonnasta. 3. Oppia käytettäviä Java-tekniikoita. 4. Viisi opintoviikkoa. Tämä ei luonnollisesti kuitenkaan ole se, josta ensimmäisenä tingitään, sillä opintoviikot ovat seurausta projektin läpiviennistä. 6.2. Asiakkaan tavoitteet Asiakkaan tarkemmat vaatimukset on määritelty vaatimusmäärittelyssä. Top-10 on asiakkaan pääasialliset tavoitteet, joiden avulla mitataan projektin onnistumista. 6.2.1. TOP-10 1. Sovelluskehikko tarjoaa HTML-lomakkeella tapahtuvat käyttäjän identifioinnin/autentikoinnin ja HTTP standardien mukaisen Basic autentikoinnin 2. Sovelluskehikon avulla voi suorittaa operaatioita vain käyttäjän käyttöoikeuksien rajoissa (verifiointi vaikeaa; sovelluskehikko voidaan todistaa aukolliseksi, ei aukottomaksi!) 3. Projektiryhmä toteuttaa valmiit rajapinnat SQL92- ja LDAP tietolähteisiin, joita voi periyttämällä muokata sovelluskohtaisiin tarkoituksiin. 4. Sovelluskehikko on asiakkaan arvion mukaan riittävän modulaarinen ja laajennettava 5. Sovelluskehikko on geneerinen, ei saa sitoutua tiettyihin tietolähteisiin 6. Riittävä suorituskyvyltään, ts. se ei saa hidastaa sovelluksen toimintaa LIIKAA. Suorituskykyrajoitteet ovat AINA sovelluskohtaisia, joten tarkkoja rajoa SOVELLUSKEHYKSELLE ei voida määrittää. Projektiryhmän tulee selvittää, kuinka voimakas sovelluskehikon suorituskykyvaikutus on. 7. Riittävän helppokäyttöinen, että sovelluskehikon käyttäminen on mukavaa ja kannattavaa Käytön helppous ja kannattavuus kokeillaan esimerkkisovelluksella. 8. Sovelluskehikon tulee tarjota myös mahdollisuus käyttöoikeuksien valvontaan sovelluksessa, jolloin sovelluskehikko toimii vain rajapintana käyttäjätietolähteeseen. PROJEKTISUUNNITELMA 15
Jussi Isotupa 16 (30) 9. Sovelluskehikko tulee dokumentoida niin hyvin, että sen käyttöönotto asiakkaan omissa projekteissa on asiakkaan arvion mukaan riittävän helppoa ja tehokasta. 10. Sovelluskehikon tulee toimia J2EE standardeja noudattavissa sovelluspalvelimissa. Tämä varmistetaan. Projektiryhmä toteuttaa myös esimerkkisovelluksen työn osana. Esimerkkisovelluksen tarkoitus ei ole olla valmis tuote, vaan sen tarkoitus on kokeilla sovelluskehikon käyttöä tositilanteessa. Asiakas EI ole kiinnostunut esimerkkisovelluksesta. Esimerkkisovelluksen toteutus ei saa siis viedä liikaa aikaa, ja sen toiminnoista tingitään ensimmäiseksi. Esimerkkisovellus esitellään vaatimusmäärittelyssä. Esimerkkisovelluksena toteutetaan yksinkertainen projektien tuntiseurantasovellus. 6.3. Projektin tavoitteet Projektin tavoitteena on toteuttaa käyttäjien tunnistamiseen ja käyttöoikeuksien hallintaan sovelluskehikko, joka tarjoaa valmiita palveluja ja ratkaisumallin ongelmakentän ratkaisemiseen. Sovelluskehikosta pyritään tekemään helposti laajennettava ja mukautettava erilaisten sovellusten tarpeisiin. 6.4. Projektin keskeyttämiskriteerit Projekti keskeytetään mikäli?? Asiakas keskeyttää projektin?? Mikäli projektia ei pystytä viemään loppuun kurssin puitteissa tai hiukan yli. Työmäärä saa ylittää 25% projektiryhmän yhteenlasketun työmäärän (6*200h=1200h), eli saa olla maksimissaan 1500h.?? Mikäli todetaan asiakkaan kanssa, että sovelluskehikon toteuttaminen ei ole mahdollista?? Mikäli todetaan asiakkaan kanssa yhteisesti, että sovelluskehikon käytöstä ei saada riittävää hyötyä?? Microsoft julkaisee kaiken kattavan ilmaisen ratkaisun, joka toimii jokaisella laitealustalla Projektin keskeyttämiseksi tarvitaan asiakkaan päätös tai projektiryhmän enemmistön päätös. Jos asiakas keskeyttää projektin, voi projektiryhmä halutessaan jatkaa kehitystä ja saa samalla täydet oikeudet projektin tuotoksiin. Projektiryhmän keskeyttäessä projektin se laatii selvityksen keskeyttämisen syistä. 6.5. Projektin päättämiskriteerit Projekti päättyy, kun?? työtunteja on projektiryhmän jäseneet tehneet yhteensä riittävästi suhteessa kurssin työmäärän. Tämä tarkoittaa 75% kurssin työmäärästä, eli (6*200h*0,75) = 900h. PROJEKTISUUNNITELMA 16
Jussi Isotupa 17 (30)?? sovelluskehikko ja esimerkkisovellus ovat vaatimusmäärittelyn mukaisia ja asiakkaan hyväksymiä?? lopputulos dokumentteineen on toimitettu asiakkaalle?? on pidetty päätöspalaveri, johon osallistuvat asiakkaan edustajat (ohjaaja ja tilaaja), projektiryhmän enemmistö sekä kurssin ohjaaja Projektiryhmä toimittaa asiakkaalle?? sovelluskehikon käännettynä?? sovelluskehikon lähdekoodit?? dokumentaation sovelluskehikkoon, joka sisältää JavaDoc-referenssit sekä ohjeen, kuinka sovelluskehystä käytetään sovelluskehityksessä?? esimerkkisovelluksen lähdekoodit?? muun projektin aikana syntyneen dokumentaation Projektiryhmä ei kouluta asiakasta sovelluskehikon käyttöön. Projektiryhmään kuuluu kaksi asiakkaan työntekijää, joten asiakkaalle jää myös syvällisempää tietoutta sovelluskehikosta. Asiakas ja asiakkaan työntekijät sopivat keskenään koulutuksen järjestämisestä, mikäli se on tarpeellista. PROJEKTISUUNNITELMA 17
Jussi Isotupa 18 (30) 7. Projektin resurssit 7.1. Henkilöresurssit Henkilökohtaisen ajankäytön arvio projektin alussa: Tomas Jussi Janne Timo Mickey Mikko Yhteensä PS 40 40 30 20 20 20 170 T1 25 25 25 25 25 20 145 T2 40 45 45 45 45 40 255 T3 30 25 35 40 40 35 210 T4 30 30 30 35 35 40 200 LU 35 35 35 35 35 45 220 Yhteensä 200 200 200 200 200 200 1200 7.1.1. Tiedossa olevat poissaolot Tomas 18.12.2000-2.1.2001 Jussi 18.12.2000-2.1.2001 20.1.2001-8.2.2001 Janne 18.12.2000-2.1.2001 Timo 18.12.2000-2.1.2001 Mickey 18.12.2000-2.1.2001 Mikko 18.12.2000-2.1.2001 7.2. Ohjaaja Projektin ohjaaja on käytettävissä, jos ja kun tarvetta ilmenee ja hänet kiinni saa. 7.3. Laiteresurssit?? palvelin ryhmän käyttöön asiakkaalta?? tarvittaessa palvelintilaa ja verkkoyhteys Weppihiiri Oy:ltä?? tarvittaessa Jussin laitteisto käytettävissä, dynaamisella IP:llä DSL-piuhan takaa PROJEKTISUUNNITELMA 18
Jussi Isotupa 19 (30) 7.4. Projektin kustannusarvio Projektiryhmä on arvioinut käyttävänsä projektiin n. 1200 tuntia työtä. Tämän lisäksi asiakkaalle tulee kustannuksia oman väen sitomisesta projektiin sekä toimitettavista laitteista ja ohjelmistoista. Työntekijöistä, laitteista ym. kuluista on arvioitu koituvan kuluja yhteensä n. 375mk/h. 1200h x 350mk/h ~ 450 000mk PROJEKTISUUNNITELMA 19
Jussi Isotupa 20 (30) 8. Projektissa käytettävät menetelmät ja työkalut 8.1. Työkalut Sovelluskehikko suunnitellaan ja kuvataan UML-kuvauskielellä. UML-työkaluja ryhmällä on käytössä?? Rational Rose, käyttöön koululta. Ei käytetä.?? TogetherJ, käyttöön asiakkaalta, vastuuhenkilönä Tomas Sovelluskehikon toteutukseen käytetään?? JBuilder, käyttöön asiakkaalta, vastuuhenkilönä Janne?? J2EE SDK 1.2.1, ilmainen, vastuuhenkilönä Jussi?? J2SE SDK 1.3.0, ilmainen, vastuuhenkilönä Jussi Jos aikaa jää, toteutetaan demoluonteisesti Microsoft COM-arkkitehtuurin mukainen rajapinta. Tähän tarvittavavat työkalut ovat Microsoft Visual Studio 6.0 + MS Visual J++ 6.0 sekä Sunin Proxy COM-komponentteihin. Microsoftin tuotteet on käytettävissä Weppihiiri Oy:n tiloissa. Vastuuhenkilö Jussi. T2-vaiheen alussa asennetaan ryhmän käyttöön palvelin asiakkaan tiloihin. Käytettävä palvelinympäristö on Windows 2000 + IBM WebSphere Application Server 3.5. Tietokantana käytetään Oracle 8i:tä. Hakemistopalvelut toteutettaneen Netscape Directory 3.0:lla. Dokumentointi tehdään Microsoft Office -työkaluilla tallettaen Office 97- formaatteihin. Katselmoitavat dokumentit konvertoidaan.pdf-tiedostoiksi, jotka laitetaan ryhmän kotisivuille, jotka löytyvät osoitteesta http://www.niksula.cs.hut.fi/~jjkankaa//index.html. Dokumentointikielenä on suomi. Referenssidokumentaatio tehdään JavaDocilla. Esimerkkisovelluksen kuormitustestaus hoidetaan Microsoftin ilmaisella Web Application Stress Tool työkalulla. Ilmaista JUnit-ohjelmaa käytetään moduulitestaukseen, jonka käytöstä Mikko Viljainen kirjoittaa testaussuunnitelmaan. Raportointiin käytetään Buranaa, Tiranaa ja tulosten tarkastaluun ViCaa. Projektin aikataulu ja resurssien allokointi tehdään MS-Project 98:lla. Projectin kanta dumpataan Tiranaa varten PMIX-ohjelmalla. PROJEKTISUUNNITELMA 20
Jussi Isotupa 21 (30) 8.2. Versionhallinta Dokumentointipäällikkö ja VAIN dokumentointipäällikkö vastaa dokumenttien yhtenäisyydestä ja versionhallinnasta. Dokumentit tulee hyväksyttää dokumentointipäälliköllä, joka liittää ne ryhmäkohtaiseen dokumentaatioon. Ryhmäkohtainen dokumentaatio talletetaan ryhmän kotisivuille. Jokaisen suuremman muutoksen jälkeen tulee dokumenttien edellinen versio pitää tallessa projektin vaiheen ajan ja versionumero päivittää. Projektin vaiheen loputtua kun vaiheen katselmus on pidetty, voidaan vaiheen väliversiot poistaa. Projektikatselmuksissa hyväksytyt dokumentit tulee säilyttää! Koodiin pätee samat periaatteet. Laatupäällikkö valvoo koodin yhtenäistä tyyliä ja virheettömyyttä sekä huolehtii versionhallinnasta. Projektin vaiheen keston aikana suurempien muutosten jälkeen edellinen versio tulee säästää. Vaiheen loputtua versiot voidaan poistaa pl. katselmuksessa hyväksytyt koodit. 8.2.1. Versionumerointi Versionumerointi toteutetaan kaksinumeroisena. Jälkimmäinen numero kasvaa joka toimituksessa, toimitus tarkoittaen tässä yhteydessä koodin liittämistä ryhmäkohtaiseen koodivarastoon. Ensimmäinen numero kuvaa projektin vaihetta. 8.3. Seurantatyökalut Buranaa käytetään projektin tuotosten koon seurantaan, opponenttiryhmän tuotoksista löydettyihin bugeihin sekä omaan bugiraportointiin. Tiranaa käytetään tuntiseurantaan, jotta projektipäällikkö voi arvioida projektin etenemistä ja aikataulua sekä hyödyntää toteutumaa seuraavia vaiheita suunnitellessa. 8.4. Tiedonkulku Tiedonvälitys hoidetaan pääasiassa sähköpostitse. Projektiryhmällä on jakelulista, teamahma@weppihiiri.com, jonka avulla saa helposti postin kaikille. 8.5. Nimeämiskäytännöt 8.5.1. Javakoodi Javassa noudatetaan Java Code Conventionia, eli luokat alkavat isoilla kirjaimilla, metodit ja attribuutit alkavat pienellä kirjaimella ja sanat alkavat nimen keskellä isoilla. Sanat kirjoitetaan yhteen. [7] class ClassExample implements NanoNano { }... int kokonaislukumalli; PROJEKTISUUNNITELMA 21
Jussi Isotupa 22 (30) for {int i = 0; i < 0; i++) { } if (i == 0) { } 8.5.2. Dokumentit Dokumentit nimetään kuvaavilla nimillä, esim. projektisuunnitelma.doc. 8.6. Suunnittelumenetelmät Luokkien mallinnus tehdään UML-notaatiolla. 8.7. Laadunvarmistus Laatupäällikkö valvoo koodin laatua, kommentointia ja dokumentteja. Testauksen yhteydessä järjestetään kooditarkistuksia, joissa koodin kirjoittaja esittelee koodin ydinajatukset tarkistajalle ja tärkeät kohdat voidaan käydä läpi rivi riviltä. Tarkistukset suoritetaan työpareittain. Laatupäällikkö EI tarkista kaikkea koodia itse, vaan valvoo tyylin ja käytäntöjen säilymistä. 8.8. Muutosten hallinta Pyritään luomaan hyvä dokumentaatio, jolloin muutosten säteily järjestelmän muihin osiin on helpommin hallittavissa. Laatupäällikkö valvoo ja ohjaa. Muutokset pyritään minimoimaan hyvällä suunnittelulla, erityisesti huolellisella rajapintojen määrittelyllä, mutta sovelluskehikon rakentamisessa muutokset ovat väistämättömiä. 8.9. Vaatimusten hallinta Muutokset sovelluskehikon vaatimuksiin tulee arvioida niiden vaikutusten perusteella. Vaikutusten perusteella arvioidaan tarvittavien muutostöiden määrä ja niiden vaikutus aikatauluun sekä lopputuotteeseen toteutettaviin ominaisuuksiin. Ryhmän työmäärän ei saa kasvaa vaatimusten muuttumisen myötä yli kurssin edellyttämän työmäärän. Projektiryhmän tekemä arvio muutosten vaikutuksesta esitetään asiakkaalle, joka hyväksyy tai hylkää haluamansa muutokset. PROJEKTISUUNNITELMA 22
Jussi Isotupa 23 (30) 9. Projektin ositus, vaiheistus ja resurssointi Tarkka resurssointi MS-Project-liitteessä. Projektin suunnittelu 26.9. 18.10.2000 Projektin suunnittelun aikana laaditaan projektisuunnitelma ja resursoidaan projektin vaiheet. Tuotettavia dokumentteja ovat projektisuunnitelma ja vaatimusmäärittely. Projektisuunnitelma esitellään ja opponoidaan 18.10.2000 kello 10-12 TKK:n päärakennuksen J-salissa. Toteutus 1 (T1) 19.10. 10.11.2000 Vaiheen aikana tehdään toiminnallinen ja tekninen määrittely sovelluskehykselle ja toteutetaan alustava prototyyppi sovelluskehyksestä. Esimerkkisovelluksen kehittäminen aloitetaan sovelluskehyksen rinnalla. Tuotettavia dokumentteja ovat?? sovelluskehikon toiminnallinen ja tekninen määrittely, alustava?? esimerkkisovelluksen toiminnallinen ja tekninen määrittely?? testaussuunnitelma?? edistysmisraportti Toteutus 1-vaiheen lopussa pidetään projektikatselmus 10. marraskuuta Spektrin Kvintin ensimmäisessä kerroksessa huoneessa 1204. Toteutus (T2) 11.11. 15.12.2000 Jatketaan sovelluskehikon määrittelyä ja suunnittelua sekä toteutusta. Esimerkkisovellus saatetaan kuntoon, jossa sovelluskehyksen käyttöä voidaan demota oikealla sovelluksella. Vaiheen jälkeen pidetään projektikatselmus Spektrissä 15. joulukuuta kello 1100, jolloin järjestetään proton demo. Vaiheen aikana toteutetaan: 1. Sovelluskehikon ensimmäinen versio 2. Tietokantarajapinta SQL-tietokantoihin käyttäen tietokantana IBM DB2:a. 3. Esimerkkisovellusta toteutetaan sen verran, että sillä pystytään demoamaan käytännössä sovelluskehikon tarjoamia palveluita.. Vaiheen aikana tuotettavat dokumentit: 1. hiotut sovelluskehikon toiminnalliset ja tekniset määrittelyt 2. hiotut esimerkkisovelluksen toiminnalliset ja tekniset määrittelyt 3. edistymisraportti 4. testausraportti PROJEKTISUUNNITELMA 23
Jussi Isotupa 24 (30) Toteutus (T3) 17.12.2000 16.2.2001 Jatketaan sovelluskehikon määrittelyä ja suunnittelua sekä toteutusta. Vaihe jakaantuu joulun molemmin puolin, jolloin on tenttikaudet, joululoma jne. Pitkä vaihe ajallisesti, mutta tehokasta työaikaa yllättävän vähän. Vaiheen jälkeen pidetään projektikatselmus 16. helmikuuta Spektrissä, jolloin järjestetään proton demo. Vaiheen aikana toteutetaan: 1. tietolähderajapinnat kuntoon 2. Relaatiotietokanta-pohjainen esimerkkitoteutus 3. protoillaan LDAP-pohjaista esimerkkitoteutusta Vaiheen aikana tuotettavat dokumentit: 1. hiotut sovelluskehikon toiminnalliset ja tekniset määrittelyt 2. hiotut esimerkkisovelluksen toiminnalliset ja tekniset määrittelyt 3. edistymisraportti 4. testausraportti Toteutus (T4) 17.2.2000 23.3.2001 Jatketaan sovelluskehikon määrittelyä ja suunnittelua sekä toteutusta. Vaihe jakaantuu joulun molemmin puolin, jolloin on tenttikaudet, joululoma jne. Pitkä vaihe ajallisesti, mutta tehokasta työaikaa yllättävän vähän. Vaiheen jälkeen pidetään projektikatselmus 22. tai 23. maaliskuuta, jolloin järjestetään proton demo. Vaiheen aikana tuotettavat dokumentit: 1. hiotut sovelluskehikon toiminnalliset ja tekniset määrittelyt 2. hiotut esimerkkisovelluksen toiminnalliset ja tekniset määrittelyt 3. edistymisraportti Luovutus 24.3.2000 27.4.2001 Viimeistellään sovelluskehikko kaikin puolin. Vaiheen aikana tuotettavat dokumentit: 1. hiotut sovelluskehikon toiminnalliset ja tekniset määrittelyt 2. hiotut esimerkkisovelluksen toiminnalliset ja tekniset määrittelyt 3. edistymisraportti 4. loppuraportti PROJEKTISUUNNITELMA 24
Jussi Isotupa 25 (30) 10. Seuranta ja ohjaus 10.1. Projektipalaverit Projektin seurantaa varten pidetään viikottainen projektipalaveri projektiryhmän kesken. Projektipalaverissa valitaan sihteeri, joka kirjaa projektipalaverissa ilmenneet asiat, ja tekee palaverista muistion. Muistio tulee tehdä ja lähettää projektiryhmän jäsenille kahden päivän sisällä palaveristä, jotteivat asiat pääse unohtumaan palaverin jälkeen. Dokumentointipäällikkö laittaa palaverimuistiot ryhmän kotisivulle. Asiakas tai ohjaaja eivät ole kiinnostuneita muistioista. Palaverit pidetään ennen luentoja luentojen ollessa käynnissä. Luentojen loppuessa valitaan uusi aika, joka sopii parhaiten projektiryhmälle. Palaverissä?? puidaan ilmenneet ongelmat ja asiat?? projektipäällikkö jakaa mahdolliset uudet tehtävät ja suorittaa ohjaustoimenpiteet?? käydään läpi projektiryhmän jäsenten edistyminen omissa tehtävissään?? arvioidaan eteneminen projektissa kokonaisuutena 10.2. Asiakaspalaverit Asiakas ei halua sitoa resurssejaan kiinteään yhteydenpitoon. Asiakkaalle riittää kahvipöytäkeskustelut projektiryhmään kuuluvan A-Waren työntekijän, eli ryhmän projektipäällikön, kanssa. Asiakaspalaverejä voidaan järjestää tarvittaessa. 10.3. Kurssin toimittamat työkalut Projektiryhmä sitoutuu käyttämään tuntiseurantaan Tirana-järjestelmää ja bugiraportointiin Buranaa kurssin ohjeiden mukaisesti. [4] [5] 10.4. Kurssin vaatimukset projektin seurannalle Kurssin vaatimuksia seurannalle pyritään noudattamaan. PROJEKTISUUNNITELMA 25
Jussi Isotupa 26 (30) 11. Standardit, direktiivit ja määräykset Toteutettava esimerkkisovellus, projektin tuntiseuranta, täyttää henkilörekisterin tunnusmerkit ja näinollen sen toteutuksessa on noudatettava henkilörekisterilakia. Testaussuunnitelma perustuu IEEE829-1983 Standard for Software Test Documentation standardiin. [6] Projektiryhmä käyttää Sunin Java Code Conventionia java-koodiin ja tekee dokumentaation luokista käyttäen Javadocia. PROJEKTISUUNNITELMA 26
Jussi Isotupa 27 (30) 12. Riskienhallintasuunnitelma Projektin luonteen vuoksi erityisesti aikatauluihin liittyvät riskit ovat todennäköisiä. Projektiryhmä on varannut aikaa paljon iteroimiselle ja hiomiselle sekä projektin uudelleenjärjestelyille. Riskienhallintasuunnitelma erillisenä liitteenä. PROJEKTISUUNNITELMA 27
Jussi Isotupa 28 (30) 13. Projektiryhmän sisäinen koulutussuunnitelma Projektipäällikkö on sitoutunut antamaan koulutusta Java Server tekniikoista, sekä Servlet-ohjelmoinnista. Projektin aikatauluun on varattu aikaa opettelulle. PROJEKTISUUNNITELMA 28
Jussi Isotupa 29 (30) Liite A. Vaiheiden palautusten muistilistat A.1. T2-vaiheen muistilista - sovelluskehikko toiminnallinen määrittely liitetty palautukseen - sovelluskehikko tekninen määrittely liitetty palautukseen - demo toiminnallinen määrittely liitetty palautukseen - demo tekninen määrittely liitetty palautukseen - koodien liittäminen palautukseen - javadocit palautukseen - UML-malli Togetherilla, liitetty palautukseen - edistymisraportti T2 liitetty palautukseen - ms project päivitetty T3 liitetty palautukseen - buranaraportti koodin ja dokumentaation määrästä tehty - tuntimerkinnät tehty tiranaan - projektisuunnitelma liitetty palautukseen - riskienhallintasuunnitelma liitetty palautukseen - testaussuunnitelma liitetty palautukseen - pmix-dump T3 tehty - palautus tehty weppiliittymän läpi PROJEKTISUUNNITELMA 29
Jussi Isotupa 30 (30) Lähdeluettelo [1] A-Ware Oy, A-Ware Oy: Internet, Java, object and data security technologies, 18.9.2000 [viitattu 12.10.2000] <http://www.aware.fi/framefin.html> [2] Sun Microsystems Inc., The Industry-Backed Server-Side Component Architecture, 6.10.2000 [Viitattu 15.10.2000] <http://java.sun.com/products/ejb/> [3] Sun Microsystems Inc., Java 2 Platform, Enterprise Edition, 12.10.2000 [Viitattu 15.10.2000] <http://www.javasoft.com/j2ee/> [4] TKK, Tik-76.115 Software project, Tik-76.115 BURANA 2000 Help Page, 14.9.2000 [Viitattu 15.10.2000] <http://mordor.cs.hut.fi/tik-76.115/ohjeet/buranahelp.html> [5] TKK, Tik-76.115 Software project, Tuntiraportointiohje, 12.9.2000 [Viitattu 15.10.2000] <http://mordor.cs.hut.fi/tik-76.115/ohjeet/tuntiraportointiohje.html> [6] ANSI/IEEE, Standard for Software Test Documentation, IEEE Standards 829, 1983 [7] Sun Microsystems, Code Conventions for the JavaTM Programming Language, 20.4.1999 [Viitattu 15.10.2000] <http://java.sun.com/docs/codeconv/index.html> Liiteluettelo [A] Riskienhallintasuunnitelma PROJEKTISUUNNITELMA 30