Teknillinen korkeakoulu Tik-76.601 Ohjelmistotuotannon perusopintojakso Project plan Henna Pietiläinen 45356D Ti Muistio projektisuunnitelmasta 1. Johdanto Sain Pauli Porholta alustavan suunnitelman projektisuunnitelmaksi ja tässä projektisuunnitelmamuistiossa olen esittänyt kohtia jotka tuohon suunnitelmaan pitäisi mielestäni lisätä ja toisaalta kohtia, jotka mielestäni sieltä pitäisi poistaa. Muistiossa on pyritty ottamaan huomioon myös Klaus Ordnungin antamat kommentit siitä, että projektisuunnitelman pitäisi olla niin niin hyvä ja kattava, että sitä pystytään seuraamaan kirjaimellisesti projektia tehtäessä. Lisäksi sain Pierre Lebumilta paljon tärkeää tietoa käyttäjien vaatimuksista ja pyrin ottamaan nekin huomioon muistiossa. Myös Niilo Nörtin esittämä mahdollinen www-sovelluksen arkkitehtuurin vaihdos ja Mary Smithin kertomat välimatkaongelmat on pyritty ottamaan mukaan muistioon. 2. Dokumentin tarkoitus Dokumentin on tarkoitus toimia apuna loppullisen projektisuunnitelman teossa ja tuoda keskusteluun mukaan omasta mielestäni tärkeitä seikkoja projektisuunnitelmassa. 3. Tilanneanalyysi Tällä hetkellä ollaan päästy SAD-projektissa siihen vaiheeseen, että projektille tarvitsee luoda selkeä suunnitelma aikataulusta ja resurssien käytöstä. Projektisuunnitelmamuistiota tehdessäni kuulin Niilo Nörtiltä että joudumme ehkä hylkäämään alunperin suunnitellun kaltaisen arkkitehtuurin ja siirtymään hajautettujen tietokantojen suunnitteluun ja tekemään web-liittymän niihin. Arkkitehtuurin muutoksen tarpeellisuus täytyy tutkia nyt lokakuun aikana, jotta kun työntekijät tulevat kursseiltaan voidaan aloittaa web-liittymän suunnittelu. Lisäksi Mary Smith oli huolissaan siitä, kuinka pitkä välimatka Softwheren ja Nowheren välillä tulee vaikuttamaan projektin läpiviemiseen. Ehdotankin että luomme projektille oman sähköisen keskustelukanavan, jonka kautta mielipiteiden ja neuvojen vaihtaminen käy nopeasti ja helposti, käytämme paljon sähköpostia ja puhelinta eri toimipisteiden välillä ja näiden lisäksi pidämme kerran kuukaudessa palaverin molempien toimipaikkojen edustajien kanssa ja muulloinkin jos tarvetta ilmenee. 4. Päämääräanalyysi Päämääränä on tehdä projektisuunnitelma, jonka tarkoituksena on kuvata miten projektille varatuilla resursseilla päästään suunnitellun aikataulun rajoissa haluttuun lopputulokseen. Projektisuunnitelmaa käytetään projektin suorituksen ajan projektin seurantaan, sen avulla havaitaan nopeasti aikataulu- ja resurssipoikkeamat, jolloin niihin voidaan välittömästi puuttua. 5. Toimenpiteet Tässä mielestäni tarpeellisia muutoksia ja lisäyksiä Pauli Porhon tekemään alustavaan projektisuunnitelmaan. 1. INTRODUCTION 1.1. Background and Motivation Mielestäni Background and Motivation -kappale on ihan hyvä sellaisenaan, sillä projektisuunnitelman tausta ja motivaatio tulevat siitä ilmi. 1.2. Document Definition Myös Document Definition -kappale on ihan hyvä sellaisenaan, sillä dokumentin tarkoitus tulee siitä hyvin ilmi. 1.3. Definitions, Terminology and Abbreaviations Lisäisin vielä seuraavat lyhenteet lyhennelistaan, sillä ne esiintyvät suunnitelmassa: ESMS Earth Satellite Monitoring System DCPSC Data Collection Processing and Storing Center GUI Graphical User Interface 1.4. Main References Mielestäni Main References -kappale on ihan hyvä sellaisenaan. 2. PROJECT DEFINITION 2.1. Scope Poistaisin kappaleesta viimeisen lauseen eli lauseen (That's what I've been told), sillä se antaa sellaisen vaikutuksen ettei suunnitelman kirjoittaja tiedä projektista tarpeeksi. 2.2. Goals Poistaisin kappaleesta kohdan 'No other people shall be able to investigate the data gathered by the system because of severe risk open systems have.', sillä oman käsitykseni ja johdannossa saamani käsityksen mukaan tietokanta olisi kaikkien kiinnostuneiden käytössä. Sitäpaitsi en ymmärrä mitä vakavia riskejä juuri avoimilla systeemeillä olisi. Lisäksi kappaleen lopussa olevaan vaatimusmäärittelyyn lisäisin vielä seuraavat seikat, jotka tulivat ilmi Pierre Lebumilta: - Järjestelmän pitää tukea datan talletusta paikallista prosessointia varten. - Järjestelmän pitää tarjota erilaisia helppejä noviisikäyttäjille ja eksperteille. - Järjestelmän pitää tukea datan hakua ja yhdistelyä eri tietokannoista. - Järjestelmän pitää päivittää dataa päivittäin ja mahdollistaa myös pääsy aikaisemmin kerättyyn dataan. - Järjestelmän pitää tukea datan visualisointia monelta eri perspektiiviltä ja erilaisilla metaforilla. - Järjestelmän pitää mahdollistaa käyttäjien luoda omia profiileita jotka määrittelevät käyttöliittymän, sisäänpääsyn ja yhteyden systeemiin. - Järjestelmästä pitää ottaa varmuuskopio, tai "klooni", jota voidaan käyttää jos järjestelmässä esiintyy kriittinen vika. - Käyttäjän liikkeitä pitää voida jäljittää käyttäjien profiloinnin mahdollistamiseksi ja eniten käytettyjen palveluiden seuraamiseksi. 2.3. Deliverables Tässä kappaleessa oli suuria asiavirheitä ja se täytyykin kirjoittaa uudelleen miltei kokonaan. Projektin tehtävänähän ei suinkaan ole tehdä tietokantoja vaan WWW- sovellus jonka kautta näistä eri tietokannoista (Atmospheric database, Pollution database, Extra terrestial database, Water resource database, Plant life database) voidaan hakea tietoa erilaisilla hakuehdoilla ja ladata tietoa paikalliselle levylle tarkempaa analyysiä varten. Mielestäni noita eri tietokantoja ei tarvitsisi edes sen tarkemmin esitellä tässä kappaleessa, mutta jos ne halutaan esitellä, ei Extra terrestial database suinkaan pidä sisällään tietoja avaruusolioiden elämästä. Lisäksi Pauli Porho unohti listasta kokonaan Pollution tietokannan ja Water resource tietokannan ja niiden kuvaukset. 3. ORGANIZATION 3.1. Project Organization Tähän kappaleeseen tekisin muutaman lisäyksen. Ajattelin jakaa SAD-projektiin osallistuvat työntekijät kolmeen tiimiin: 2 tiimiä hoitaisi WWW-sovelluksen toteuttamisen ja yksi tiimi hoitaisi testaukseen liittyvät asiat. Jakaisin vielä tuon WWW-sovelluksen toteuttamisen kahden tiimin välillä siten että toinen tiimi hoitaisi käyttöliittymän suunnittelun ja toteutuksen ja toinen sovelluksen toiminnallisen puolen suunnittelun ja toteutuksen. Kun työ olisi jaettu tällä tavoin pienemmille ryhmille voisi kukin tiimi keskittyä paremmin omaan työalueeseensa. Lisäisin siis kappaleeseen seuraavat henkilöt: - Pekka Pehmo, Softwheren toimitusjohtaja - Pauli Porho, myyntipäällikkö - Keijo Käyli, käyttöliittymätiimin johtaja - Timo Toiminta, toiminnallisuustiimin johtaja - Tero Testi, testaustiimin johtaja Mielestäni Pekka Pehmolla ja Pauli Porholla on myös tärkeä rooli tässä projektissa, joten myös heidät on syytä mainita listassa. 3.2. External Contact Persons and Groups Tähän kappaleeseen lisäisin asiakkaan edustajiin lisää tietoja: - Klaus Ordnung, contract manager. - Pierre Lebum, käyttäjien edustaja. - Luigi Vermicelli, tekninen johtaja. Mielestäni on tärkeää että sekä käyttäjien että tekniikan edustaja on nimetty myös asiakkaan puolelta, ettei myöhemmin synny epäselvyyksiä siitä ketkä ne viralliset edustajat taas olivatkaan. Tämän lisäksi uskon että projektissa olisi tarvetta kahdelle yrityksen ulkopuoliselle laadun tarkkailijalle, jotka voisivat valvoa koko projektin laatua. 4. PROJECT PHASES AND PHASE OUTPUTS 4.1. Main tasks 4.1.1. Specification Mielestäni meidän pitää käydä asiakkaan kanssa läpi selkeä vaatimusmäärittely siitä mitä kaikkea WWW-sovellukselta halutaan. Keijo Käyli ja Timo Toiminto voisivat toimia vastuuhenkilöinä. Keijo Käyli selvittäisi käyttöliittymän vaatimusmäärittelyn ja Timo Toiminto toiminnallisuuden vaatimusmäärittelyn. 4.1.2. System Design Mielestäni Niilo Nörtti voisi toimia systeemin suunnittelun vastuuhenkilönä. Hänellä on selkeästi eniten tietoa järjestelmien arkkitehtuurista ja modulaarisuudesta. Keijo Käyli ja Timo Toiminta tiimeineen voisivat avustaa häntä ja esittää ideoita. 4.1.3. Implementation Mielestäni käyttöliittymätiimi ja toiminnallisuustiimi voisivat huolehtia WWW-sovelluksen toteuttamisesta. Vastuu voitaisiin jakaa tiimeittäin siten että Keijo Käyli vastaa käyttöliittymästä ja Timo Toiminto toiminnallisuudesta. 4.1.4. Testing Mielestäni testauksen voisi hoitaa testaustiimi ja vastuuhenkilöksi valittaisiin testaustiimin johtaja Tero Testi. 4.2. Documentation Plan Projektisuunnitelman lisäksi tarvitsee tuottaa myös seuraavat sisäiset dokumentit: - Vaatimusmäärittely - Kustannusarvio - Arvio riskeistä - Toiminnallinen määrittely - Tekninen määrittely - Testaussuunnitelma - Testiraportti - Käyttöohje - Loppuraportti - Useita edistymisraportteja - Pöytäkirjat kaikista tiimien ja projektin palavereista 5. DEVELOPMENT STRATEGY Tästä kappaleesta poistaisin kohdan 'To ensure smooth development we will hire an external company to monitor the progress. One external super- visor for each programming team would do.' Uskon nimittäin että kaksi laadunvalvojaa riittää valvomaan koko projektia. Lisäksi kun nämä laadunvalvojat eivät valvo vain tiettyä tiimiä, vaan koko projektia saavat he projektista laajemman käsityksen ja pystyvät ehkä helpommin valvomaan koko projektin laatua. Kappaleen lopussa olevan lauseen täydentäisin siten että sekä Softwheren ja SAD:n hallinnolliset henkilöt ovat tekemisissä projektin kanssa jotta varmistetaan projektin laatu ja asiakkaan toiveiden täyttyminen. 6. PROGRESS PLAN 6.1. Work Breakdown Structure Tässä kappaleessa Pauli Porholle oli tullut varmaan kirjoitusvirhe, sillä section 0 sijasta pitäisi lukea section 4, sillä siellähän luetellaan ne projektin eri vaiheet. 6.2. Interdepedencies between Tasks Projektin edetessä syntyy seuraavat riippuvuudet eri projektien osien välillä: Projektisuunnitelma on saatava valmiiksi ennen kuin mitään muuta pystytään tekemään, sillä siinä vasta päätetään käytettävät resurssit ja aikataulu projektille. Projektisuunnitelman jälkeen tarvitaan vielä tarkennettu vaatimusmäärittely asiakkaalta, jotta tiedetään mitä kaikkea projektin lopputuloksessa pitää olla. Nyt voidaan projektisuunnitelman ja vaatimusmäärittelyn pohjalta tehdä kustannusarvio ja kun kustannusarvio on valmis voidaan sen pohjalta tehdä arvio riskeistä. Toiminnallinen määrittely voidaan tehdä heti vaatimusmäärittelyn jälkeen, sillä kun tiedetään lopputuotteelta vaadittavat vaatimukset, voidaan toiminnallinen määrittely tehdä. Tekninen määrittely voidaan tehdä vasta kun toiminnallinen määrittely on tehty, sillä muuten ei tiedetä millainen järjestelmä pitäisi teknisesti määrittää. Testaussuunnitelma voidaan tehdä vasta teknisen määrittelyn jälkeen, sillä kun tiedetään millä tekniikoilla järjestelmä ollaan toteuttamassa voidaan sitä testasta mahdollisista heikoista kohdista. Käyttöohje voidaan tehdä heti toiminnallisen määrittelyn jälkeen, jolloin tiedetään mitä kaikkea toiminnallisuutta järjestelmässä tulee olemaan. 1. prototyyppi voidaan tehdä vasta kun kaikki nämä edelliset vaiheet on suoritettu, sillä vasta silloin tiedetään tarpeeksi prototyypin vaatimuksista. Prototyyppin testaus tapahtuu tietysti vasta prototyypin valmistumisen jälkeen ja testiraportti kirjoitetaan vasta testauksen jälkeen. Viimeisenä projektin vaiheena on kokoavan loppuraportin kirjoitus. 6.3. Time Schedule Mielestäni seuraava aikataulu olisi hyvä. Vasemmalla oleva päivämäärä kertoo sen päivän jolloin työn pitää viimeistään olla valmis. 2.10.1998 Projektisuunnitelma 16.10.1998 Vaatimusmäärittely 1.10 - 3.11.1998 Koulutus 30.10.1998 Kustannusarvio 13.11.1998 Arvio riskeistä 27.11.1998 Toiminnallinen määrittely 11.12.1998 Tekninen määrittely 31.12.1998 Testaussuunnitelma 31.12.1998 Käyttöohje 1.3.1999 1. Prototyyppi 2.3 - 16.3.1999 1. Prototyypin testaus 22.3.1999 Testiraportti 23.3 - 24.5.1999 Tarvittavat korjaukset 25.5.1999 2. Prototyyppi 26.5 - 9.6.1999 2. Prototyypin testaus 15.6.1999 Testiraportti 16.6 - 16.8.1999 Tarvittavat korjaukset 17.8.1999 3. Prototyyppi 20.8 - 24.8.1999 3. Prototyypin testaus 31.8.1999 Loppuraportti Tällä aikataululla myös riippuvuudet eri projektien osien välillä on otettu huomioon. 6.4. Deployment Plan Mielestäni projektissa on syytä kehittää ainakin hyvien dokumenttien laatimista, jotta tulevaisuudessa tässä projektissa opittuja asioita voidaan käyttää hyväksi. Sen lisäksi huomiota pitäisi kiinnittää työntekijöiden työtapojen kehittämiseen, oikeanlaisten testaustapojen löytämiseen ja siihen että lopputuote vastaa mahdollisimman hyvin asiakkaan toiveita. 7. PROGRESS CONTROL Mielestäni tiimien raportit ovat hyvin tarpeellisia. Tiimien pitäisikin kirjoittaa kaikista palavereistaan pöytäkirjat ja toimittaa ne minulle. Sen lisäksi tiimin edistymisraportit kerran kahdessa viikossa olisivat hyödyllisiä, jotta nähdään pysytäänkö projektin aikataulussa. 8. QUALITY ASSURANCE 8.1. Quality Management Mielestäni tähän kappaleeseen ei tarvita muutoksia, sillä siitä käy ilmi kaikki ne standardit, joihin projektin laatu perustuu. 8.2. Supporting Activities Softwherelle palkataan kaksi yrityksen ulkopuolista laadunvalvojaa valvomaan koko projektin laatua. Sen lisäksi sekä Softwheren että SAD:n hallinto pitää tiiviisti yhteyttä projektiin ja valvoo omalta osaltaan projektin laatua. 9. TRAINING AND CONSULTANCY 9.1. Training Plan Mielestäni koulutusta voitaisiin järjestää muuallakin kuin Nowheren ja Softwheren toimitiloissa. Jos siis jossain toisella puolella maapalloa löytyisi paljon koulutusta haluavia voitaisiin sinne lähettää joku kouluttamaan heitä. 9.2. Consultancy Required Mielestäni voisimme pyytää jotain satelliittiasiantuntijaa konsultoimaan etenkin WWW-sovelluksen käyttöliittymää tekevää tiimiä alan terminologiasta ja käsitteistä. 10. RESOURCE PLANNING Lisäisin tähän listaan myös muut projektiin osallistuvat ihmiset eli: - Pauli Porho, Softwheren myyntiedustajana hoitaa myös monia muita projekteja, ei siis aina projektin käytettävissä. - Henna Pietiläinen, projektin vastaava, aina projektin käytettävissä. - Mary Smith, Nowheren johtaja, aina projektin käytettävissä. - Niilo Nörtti, Tuotekehitysvastaava, toimii myös muissa projekteissa, ei siis aina projektin käytettävissä. - Voitto Markkanen, Tuote-edustaja, toimii myös muissa projekteissa, ei siis aina projektin käytettävissä. - Keijo Käyli, Käyttöliittymätiimin johtaja, aina projektin käytettävissä. - Timo Toiminto, Toiminnallisuustiimin johtaja, aina projektin käytettävissä. - Tero Testi, Testaustiimin johtaja, aina projektin käytettävissä. 11. FUTURE DEVELOPMENT Jättäisin viimeisen lauseen pois, sillä mielestäni projektisuunnitelman hyväksymisen jälkeen ei sitä enää pidä muuttaa. 12. REFERENCES Ei tarvitse muutoksia. 6. Lopputulokset Ehdotukset muutoksista projektisuunnitelmaan olivat tässä perusteluineen. Niiden avulla olisi tarkoitus saada projekti vietyä läpi. Muistiossa on nyt määritelty projektin tarvitsemat resurssit, aikataulu ja tukitoiminnot. Näiden avulla projektin seuranta on selkeää ja poikkeamat resurssien käytöstä ja aikataulusta havaitaan helposti ja nopeasti, jolloin niihin voidaan puuttua.