![[phpwiki]](images/keltsi_logo.gif){kind=logo}
Projektisuunnitelma
Projektisuunnitelma
Kansilehti [1.]
Sisällys:
Lähteet [57.]
1. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Kansilehti)
Kansilehti
25.6.2002
Antti Hätinen Arno Aalto Merja Jalava Petri Lindgren Tuomo Kajava
2. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Johdanto)
Johdanto
Tämä dokumentti on Keltaiset sivut -ohjelmistotuotantoprojekti Keltsin projektisuunnitelma. Projektisuunnitelmassa esitetään projektin kuvaus, projektissa käytetty menetelmä, alustava iteraatiosuunnitelma, aikataulu ja resurssit, sekä käytetyt työkalut. Lopuksi mietitään erilaisia projektin riskejä, ja kuinka niihin varaudutaan.
3. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Projektin%20kuvaus)
Projektin kuvaus
Keltsi-projektissa rakennetaan semantic web -teknologian avulla uudenlaisia Keltaisia sivuja. Projektin tavoitteena on luoda proof of concept -tyyppinen prototyyppi käytettävästä teknologiasta, jonka avulla voidaan arvioida sen toimivuutta ja tarvittavaa kehitystyötä.
Projektissa käytetään Extreme Programming (XP)-ohjelmistotuotantomenetelmää yhdessä käyttöliittymäsuunnittelumenetelmän kanssa. XP:ssä tehdään nopeita yhden tai kahden viikon mittaisia iteraatioita, joiden aikana tehdään pieniä mutta hyvälaatuisia laajennuksia ohjelmaan. Tämän vuoksi projektin laajuus tai lopputulos voidaan määrittää ainoastaan käytössä olevien resurssien suhteen.
Ryhmän kannalta projektin tavoitteena on kerätä kokemusta käytännön ohjelmistotuotannosta ja käytetyistä työkaluista. Projektin tuloksena syntyvää dokumentaatiota käsitellään seuraavassa luvussa.
4. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Menetelm%E4)
Menetelmä
Keltsi-projektissa käytetään extreme programming (XP) ohjelmistotuotantomenetelmää [Beck00 [5.] ] soveltuvin osin yhdessä käyttöliittymäsuunnittelumenetelmän [Laakso01 [6.] ] kanssa.
5. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Beck00)
Beck00
Beck01 Beck K., Extreme Programming Explained - Embrace Change. 2001
6. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Laakso01)
Laakso01
Sari Laakso Käyttöliittymät - luentomoniste 2001.
7. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Extreme%20Programming)
Extreme Programming
Extreme programming on uusi perinteisistä menetelmistä radikaalisti poikkeava ohjelmistotuotantomenetelmä. XP on yksi uuden suuntauksen ohjelmistotuotantomenetelmistä, jotka pyrkivät keveyteen vastapainona esim. Rational Unified Process (RUP), jossa dokumentointi yms. on taas hyvin pitkälle vietyjä. Oikeastaan XP:n tavoissa toimia ei sinänsä ole mitään uutta. Kyseisiä menetelmiä on käytetty ja kokeiltu koko ohjelmistotuotannon historian ajan. Mikä XP:ssä on uutta, on sen tapa yhdistää erilaiset menetelmät tasapainoiseksi kokonaisuudeksi, jossa yksittäisten toimintatapojen heikkoudet ja vahvuudet tukevat saumattomasti toisiaan.
Beck esittää kirjassaan [Beck00 [5.] ] neljä ohjelmistotuotekehityksen parametria; hinta, aika, laajuus ja laatu. Mitkä tahansa kolme näistä parametreista voidaan kiinnittää ja neljäs parametri on sen jälkeen niistä riippuvainen. Esimerkiksi perinteisessä vesiputousmallissa määrittelyvaiheessa kiinnitetään projektin laajuus määrittelemällä ohjelmiston ominaisuudet, lukitaan aikataulu ja saadaan käyttöön tietyt resurssit tiettyyn hintaan (työntekijöiden työaikaa, tiloja, työkoneita). Tällöin muuttuvaksi parametriksi jää laatu. Käytännössä tämä tarkoittaa vesiputousmallin mukaisessa projektissa, että aikataulun lähestyessä loppuaan kiireen yllättäessä jätetään testausvaihe suorittamatta. Tällöin ohjelmiston laatu kärsii väistämättä. Ohjelmiston laatu on perinteisten menetelmien avulla tehtynä suuri ongelma. XP pyrkii sen sijaan tekemään hyvää laatua, sillä asiakkaalle kaatuileva ja käyttökelvoton ohjelmisto ei ole minkään arvoinen. Johtuen bisnesmaailman realiteeteista XP:ssä resurssit ja aikataulu (time to market) ovat edelleen rajoitettuja. Mutta laadusta tinkimisen sijaan XP ottaa käyttöön nopeita iteraatioita, joiden avulla projekti saa toimitettua parin viikon välein täysin testatun ja korkealaatuisen tuotteen asiakkaalle. XP käyttää monia erilaisia toimintatapoja saavuttaakseen projektin tavoitteet. XP -menetelmän sielu pyörii pitkälti automaattisten testien ympärillä. Ideana on kirjoittaa ohjelmasta testi ennen itse lähdekoodin kirjoittamista. Tällöin testejä voidaan käyttää määrittelytyökaluina; kun testi menee läpi, ominaisuus on valmis. XP:n testit voidaan jakaa kahteen tyyppiin; yksikkötesteihin ja funktionaalisiin testeihin. Yksikkötesteissä testataan, että myöhemmin kirjoitettu koodi toimii kuten sen on tarkoituskin. Funktionaalisten testien avulla määritellään iteraatioiden sisältö. Funktionaalisten testien läpimenoprosentin avulla voidaan seurata missä vaiheessa ohjelmiston kokonaiskehitys on.
Nopeiden iteraatioiden avulla voidaan toimittaa asiakkaalle täysin testattu ja integroitu versio ohjelmasta 1-3 viikon välein. Yhden iteraation aikana ryhmä suunnittelee, testaa, ohjelmoi ja integroi jonkin asiakastarinan täydellisesti. Tämä mahdollistaa samalla myös suuren joustavuuden. Asiakas näkee nopeasti mitä projekti on tuottamassa, ja pystyy nopeasti muuttamaan projektin suuntaa kun se on tarpeellista. Vesiputousmallissa yhden iteraation pituus saattaa olla jopa 2 vuotta, jonka jälkeen saatetaan huomata, ettei alun perin suunnitellun kaltaista ohjelmistoa enää tarvita.
Perinteisesti nopeat iteraatiot johtavat pian spagettikoodiin, kun ominaisuuksia lisätään toisensa perään. Tämän takia lähdekoodia täytyy aika ajoin refaktoroida, eli muuttaa sen sisäistä toimintatapaa muuttamatta sen ulkoista käyttäytymistä. Arkkitehtuurin muuttaminen toimivasta ohjelmasta on perinteisesti myös hyvin riskialtista toimintaa. Muutoksen jälkeen ei koskaan tiedetä toimiiko ohjelma samalla lailla kun se toimi ennen muutosta, ja useimmissa tapauksissa se ei toimikaan. Automaattisten testien avulla voidaan kuitenkin nopeasti ja vaivattomasti nähdä mitkä ominaisuudet toimivat refaktoroinnin jälkeen ja mitkä eivät. Näin voidaan kivuttomasti varmistaa koodin muunneltavuus.
Pariohjelmoinnin avulla pyritään lisäämään tiimin sisäistä kommunikointia ja oppimista. Ideana on, että kaksi henkilöä on yhden tietokoneen ääressä tekemässä yhteistä työtehtävää. Toisen kirjoittaessa ohjelmakoodia toinen pystyy paremmin miettimään ongelmaa kokonaisuudessaan ja samalla huomaamaan mahdollisia kirjoitusvirheitä. Näin säästetään debuggausaikaa ja pystytään saavuttamaan tavoite nopeammin. Samalla voidaan myös yhdistää kahden henkilön tietämys, jolloin ongelmatapauksissa voidaan nopeasti kysyä toiselta apua. Tarkoitus on vaihtaa työskentelypareja joka päivä sen mukaan ketkä parhaiten hallitsevat käsillä olevat ongelmat.
Jotta pariohjelmointi voisi toimia, ohjelmakoodi täytyy olla kaikkien yhteisessä omistuksessa. Kukaan yksittäinen henkilö ei omista mitään ohjelmakoodia, vaan kaikilla on lupa tehdä muutoksia kaikkeen koodiin. Käytännössä tämä tarkoittaa, että on sovittava yhteisistä ohjelmointistandardeista, jotta koodin ulkoasu on yhtenäistä. Muussa tapauksessa suuri osa työajasta kuluu toisten koodin ulkoasun muuttamiseen ja siitä riitelyyn. Projektissamme olemme valinneet Sun Java Coding Convention:n yhteiseksi koodaustyyliksemme ilman Javadocia http://java.sun.com/docs/codeconv/.
XP:n iteraatiot määritellään asiakastarinoiden avulla. XP-menetelmässä asiakas kirjoittaa asiakastarinat CRC-korteille, jotka ovat B3 -kokoisia paperi- tai pahvikortteja. Meidän menetelmässämme käyttöliittymäsuunnittelija kirjoittaa asiakastarinat goalien ja projektivaatimusten pohjalta.
Planning Game on XP:n suunnittelumenetelmä. Planning Gameja on kahden tasoisia. Release Planning Game:n avulla suunnitellaan projektin iteraatioita ja niiden prioriteettiä. Tällöin bisnesihmiset ja tekniset ihmiset kokoontuvat arvioimaan asiakastarinoihin liittyvää riskiä. Aluksi bisnesihmiset jakavat asiakastarinakortit kolmeen pinoon (1-3) sen mukaan minkälaisia bisnesmahdollisuuksia niihin liittyy. Tämän jälkeen tekniset ihmiset arvioivat kuinka tarkkaan he tietävät kuinka kauan aikaa jonkin ominaisuuden toteuttamiseen kuluu aikaa. Tämä mittaa asiakastarinoiden riskiä. Alimpaan riskiluokkaan kuuluu asiakastarinat, joiden toteuttamisajan kehittäjät tietävät tarkalleen, sillä ovat tehneet sen useita kertoja aikaisemminkin. Keskikokoiseen riskiin kuuluu asiakastarinat, joiden toteuttamisajan kehittäjät osaavat arvioida jotenkin. Korkeimpaan riskiin kuuluu sellaiset asiakastarinat, joiden toteuttamisajasta kehittäjillä ei ole mitään kuvaa.
XP:ssä projektin etenemistä mitataan käyttäen hyväksi projektin nopeutta (velocity), joka kertoo kuinka paljon tiimi saa kirjoitettua uutta koodia viikoittain. Toinen tärkeä mittari on funktionaalisten testien läpimenoprosentti, jolla mitataan projektin etenemistä. Yksikkötestien läpimenoprosentti kertoo taas onko nykyinen koodi ehjä vai rikki. Muu kuin 100% läpimenoprosentti kertoo, että koodiin on tehty muutoksia, jotka särkevät aikaisempaa toiminnallisuutta. Kolmantena mittarina käytetään tuntikirjanpitoa. Jokainen tiimin jäsen kirjoittaa Wikiwikiweb-dokumentaatioon joka viikko käyttämänsä tuntimäärään.
XP ja dokumentointi
Javadoc ja koodin kommentointi
Mihin koodin kommentointia tarvitaan? Eräs tarve on, että muutkin pystyvät ymmärtämään koodin toiminnan kuin koodin kirjoittaja. XP:ssä tähän tavoitteeseen pääsemiseen käytetään kahta muuta menetelmää kuin koodin kommentointi; collective code ownership ja yksikkötestit. Ongelmana kommentoinnissa on, että se aiheuttaa ylimääräistä työtä muutenkin kuormitettuun päivärutiiniin. Pelkästään suunnittelu, yksikkötestien tekeminen ja integrointi koodauksen lisäksi ovat hyvin aikaavieviä askeleita. Mikäli tähän joudutaan lisäämään runsaasti ylimääräistä dokumentaatiota, projektin nopeus tulee hidastumaan merkittävästi. Tarkoitus kuitenkin olisi saada jotain aikaiseksikin. Yksi XP:n periaate on Travel light, jossa viitataan paimentolaisiin, joilla on mukanaan vain teltta ja yksinkertaisia ruuanvalmistusvälineitä. Paimentolaiset liikkuvat kameleiden perässä ja vaihtavat paikkaa usein, he eivät pysty käyttämään vähäisiä resursseja toimintansa ylös kirjoittamiseen, vaan kansantarinat välittyvät suullisena. Vastaavasti XP-projekti kulkee jatkuvasti paikkaansa muuttavien asiakasvaatimusten ja tekniikan perässä, jolloin raskaalla kuormalla ei pysytä muutosten perässä.
Collective Code Ownership tarkoittaa, että kaikki ryhmän jäsenet saavat tehdä muutoksia mihinkä tahansa CVS puun osaan. Vastaavasti vesiputousmallissa työ ositetaan yksittäisille henkilöille, jolloin ryhmäläiset eivät saa mennä sorkkimaan muiden tekemiä ohjelmanpätkiä ja kaikki muutokset tulee mennä yhden henkilön kautta. Vesiputosmallin perinteisessä tavassa ongelmana on, ettei ole mitään takuuta siitä että muun henkilön tekemän muutoksen jälkeen ohjelma toimisi enää samalla lailla kuin se toimi ennen muutosta. XP:ssä ohjelman toiminnallisuus kuitenkin varmistetaan automaattisilla testeillä, jolloin refaktoroinnin jälkeen voidaan aina tietää toimiiko koodi samalla tavalla kuin se toimi ennen muutosta siitä menevätkö testit läpi vai ei. Yksikkötestit mahdollistavat koodin yhteisomistuksen, jonka kautta kaikki tuntevat periaatteessa koko koodin.
Koodin yhteisomistus asettaa kuitenkin tiettyjä vaatimuksia sille minkälaista koodia kirjoitetaan. Jos Maijan mielestä {:tä edeltää välilyönti ja Matin mielestä ei, ongelmaksi syntyy minkälaista koodaustyyliä käytetään. Pahimmassa tapauksessa Matti käy illalla poistamassa välilyönnit ja Maija lisää ne takaisin aamulla. Koodin kirjoittamista varten täytyy siis sopia yhteinen Coding Standard, joka voi olla mikä tahansa mistä päästään yhteisymmärrykseen. Se on hyvä dokumentoida ja yhteneväinen tyyli ja nimeämiskäytännöt auttavat myös koodin luettavuudessa suuresti. Käytössämme on Sun:n Java Coding Convention.
Välttämättä kaikkea kommentointia ei tarvitse jättää tekemättä. Kuitenkin on täysin turhaa käyttää aikaa kommentoinnin käyttämiseen ryhmän sisäisenä kommunikointikeinona, kun työskentelemme yhteisessä tilassa ja voimme vaihtaa tietoa helpommin suullisesti kuin kirjoitetussa muodossa.
Mitä tulee ryhmän ulkoiseen kommunikointiin, niin automaattiset testit (ja asiakastarinat) näyttelevät myös tärkeää osaa siinä mitä koodi oikeastaan on. Ne määrittelevät koodin ulkoisen käyttäytymisen. Tällöin koodin sisäistä rakennetta voidaan muuttaa tarvittaessa (liikkua kamelien perässä) refaktoroimalla sitä. Testien ansiosta voidaan edelleen olla varmoja sen ulkoisen toiminnan muuttumattomuudesta. Koska muutos ja refaktorointi on jatkuvaa, on äärimmäisen tärkeää XP-menetelmässä, että muutoksen tekeminen on halpaa. Tällöin ylimääräinen kommentointi puukottaa menetelmää vakavasti. Lisäksi koodin rakenteen kuvaaminen on lähes mieletöntä, sillä se periaatteessa muuttuu viikoittain. Ja sen on tarkoituskin muuttua. Yksikkötestien avulla voidaan kuitenkin määritellä koodinpalasen skooppi, jonka jälkeen etsitään yksinkertaisin mahdollinen toteutus. Useimmissa tapauksissa ratkaisu ei toivonmukaan ole monimutkainen (muuten epäonnistutaan yksinkertaisuus-periaatteessa).
Jos kooditason kommentointi jätetään pois, tulee kuitenkin systeemitason arkkitehtuurikuvausten tehdä design patternien avulla. Pienten koodipätkien kuvaamisen sijasta myös myöhemmille koodin käyttäjille (ja meille itsellemme) on hyödyllisempää piirtää yleiskuva järjestelmästä ja sen suunnitteluperiaatteista.
5. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Beck00)
8. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?K%E4ytt%F6liittym%E4suunnittelumenetelm%E4)
Käyttöliittymäsuunnittelumenetelmä
Käyttöliittymäsuunnittelumenetelmässä ideana on tutkia aluksi käyttäjiä ja selvittää heidän todelliset tavoitteensa, goalit. Käyttäjiä tutkitaan ensisijaisesti tarkkailumenetelmillä. Myös haastatteluja voidaan käyttää [Hätinen02 [9.] ]. Goalit voidaan selvittää tutkimalla käyttäjien nykyinen työnkulku (task analysis). Tärkeää on myös käyttäjien tunteman kielen ja käsitteiden selvittäminen, jotta uuteen käyttöliittymään saadaan oikeiden käyttäjien tuntemia termejä eikä esimerkiksi 20-vuotiaiden tietojenkäsittelytieteenopiskelijoiden tuntemia termejä.
Tämän jälkeen goalit priorisoidaan tärkeysjärjestykseen ja niiden pohjalta laaditaan uusi työnkulku ja käyttöliittymäsuunnitelma. Suunnittelussa käytetään hyväksi käyttöliittymäsuunnittelumalleja (design pattern). Uusi käyttöliittymä piirretään A3-papereille ja sille suoritetaan goalipohjainen läpikäynti, jotta voidaan varmistaa, että käyttäjät todella pääsevät tavoitteisiinsa optimaalisella tavalla uuden työnkulun avulla. Muutaman iteraation jälkeen suunnitelmasta laaditaan paperiprototyyppi, jota testataan oikealla käyttäjällä. Näin voidaan huomata asioita, joihin suunnittelijat eivät ole kiinnittäneet huomiota.
9. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?H%E4tinen02)
Hätinen02
Hätinen A. J., Käyttäjien tavoitteiden selvittäminen kenttätutkimusmenetelmillä. Helsingin Yliopisto, tieteellisen kirjoittamisen kurssin tutkielma, 2002.
10. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Extreme%20Programming%20ja%20k%E4ytt%F6liittym%E4suunnittelumenetelm%E4%20yhdess%E4)
Extreme Programming ja käyttöliittymäsuunnittelumenetelmä yhdessä
XP ja käyttöliittymäsuunnittelumenetelmä eroavat toisistaan fundamentaalilla tavalla siinä kuinka ne suhtautuvat asiakkaaseen. XP:n ideana on joustaa asiakkaan tekemien muutoksien mukana mahdollisimman joustavasti. Käyttöliittymäsuunnittelumenetelmä taas pyrkii näkemään asiakkaan todellisen tarpeen paremmin kuin asiakas pystyy itse ilmaisemaan.
Periaatteessa käyttöliittymäsuunnittelumenetelmän avulla ei tarvita XP:n joustavuutta, mutta käytännössä on turvallisempaa riskien kannalta mikäli käytössä oleva menetelmä antaa luonnostaan pelivaraa riskien suhteen. Sen sijaan käyttöliittymäsuunnittelumenetelmä korvaa XP:n onsite-asiakkaan interaktiosuunnittelijalla, joka tutkii käyttäjiä ja suunnittelee uuden käyttöliittymän. Interaktiosuunnittelija toimii kahden maailman välissä kääntäen asiakkaan tarpeet ohjelmoijien ymmärtämälle kielelle.
Käyttöliittymäsuunnittelumenetelmän goalit ovat hyvä laajennus XP:n asiakastarinoille. Interaktiosuunnittelija tutkii käyttäjien todellisia tavoitteita, joista hän laatii asiakastarinoita iteraatioiden määrittelyksi.
Suhteessa XP:n, käyttöliittymäsuunnittelumenetelmä vaatii ylimääräisen hidastavan tutkimus ja suunnitteluvaiheen projektin alkuun, joka on XP:n filosofian vastainen. Perinteisellä XP-menetelmällä tässä tapauksessa muulla tiimillä ei olisi asiakastarinoita, eivätkä he voisi tehdä mitään. Projektin alkuvaiheessa kuitenkin useinkaan ohjelmiston käyttöliittymää lähellä olevia asioita ei muutenkaan päästä tekemään. Tällöin voi olla mahdollista, että sillä välin kun interaktiosuunnittelijat tutkivat käyttäjiä ja laativat käyttöliittymäsuunnitelmaa, muu tiimi voi keskittyä tuotekehitysympäristön pystyttämiseen ja teknologiaprototyyppien laatimiseen. Tällöin yhdistetyn XP/Käli-menetelmän ensimmäiset kaksi iteraatiota ovat tuotekehitysympäristön pystyttäminen ja prototyyppi-iteraatio. Vasta kun käyttöliittymäsuunnitelma valmistuu, voidaan aloittaa oikeiden asiakastarinapohjaisten iteraatioiden planning game ja toteuttaminen.
11. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Dokumentit)
Dokumentit
Projektitason dokumentaatio:
Projektisuunnitelma [0.] Kuvaus käyttäjistä ja goaleista [12.] (profiilit, goalit) Käyttöliittymäsuunnitelma? (A3-papereilla, goal walkthrough-sarjakuvat) Käyttöohje? tavallisille käyttäjille Loppuraportti?
Iteraation aikana tehtävä dokumentaatio:
CRC-kortit? iteraation tehtävistä, arvio kestosta ja riskistä Systeemitason arkkitehtuurikuvaus? ja suunnittelumallit Pöytäkirjat [14.] kokouksista Tuntikirjanpito [22.] WikiWikiWeb -käytännön ohjeet?
Dokumentaatioon käytetään ensisijaisesti WikiWikiWebi?ä, mutta ongelmana on kuinka tätä dokumentaatiota voidaan printata, sillä se on hypertext-muodossa. Dokumentaation tulostamista vältetään, mutta työn palautuksen yhteydessä WikiWikiWebiin? koottu materiaali tulostetaan myös kurssimappiin.
Koodia pyritään vähän myös kommentoimaan, mutta javadoc:ia ei tehdä.
0. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Projektisuunnitelma)
12. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Goalit)
Goalit
Dokumentissa kuvataan Keltsi-järjestelmän käyttäjät ja intressiryhmät, sekä heidän tavoitteensa (goalit).
Käyttäjät kuvataan käyttäen Cooperilaisia persoonia (Cooper00 [13.] ), eli ei oikeita vaan keksittyjä henkilöitä. Persooniin pyritään kiteyttämään tärkeimmät käyttäjäryhmien yhteiset ominaisuudet konkreettisiin esimerkkeihin.
Goalit, eli käyttäjien todelliset tavoitteiden selvittämiseen on käytetty haastatteluja. Projektin asiakasta (Eero Hyvönen) on haastateltu kerran, ja Keltaiset Sivut Oy:ssä on käyty haastattelemassa teknistä päällikköä Arto Raudaskoskea ja osastopäällikkö Irmeli Rämöä. Jatkossa olisi hyvä haastatella ja observoida oikeita keltaisien sivujen käyttäjiä, mikäli tähän saadaan mahdollisuus.
13. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Cooper00)
Cooper00
Cooper A., The Inmates Are Running the Asylum. 2000.
14. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?P%F6yt%E4kirjat)
Pöytäkirjat
Pöytäkirjat:
Esityslistat (haku)
Esitelmäaiheet [21.]
15. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Ryhm%E4kokous2002-05-31)
Ryhmäkokous2002-05-31
Ryhmäkokous B436 Paikalla: Antti, Merja, Petri ja Tuomo
Päätettiin käyttää XP ja käli-menetelmiä.
Sovittiin aikataulusta. Sovittiin yhteiset työajat á 5-6h tiistaisin klo 9-14 (jonka jälkeen 14-16 kokous ohjaajien kanssa), torstaisin klo 10-16 ja perjantaisin klo 9-14, (jonka jälkeen taas kokous klo 14-16). Työaikoina tullaan laitokselle, jossa tehdään töitä parityönä Planning game:ssä tehdyn suunnitelman mukaan.
Sovittiin käytettäväksi seuraavia työkaluja:
16. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Kokous2002-05-31)
Kokous2002-05-31
Älykkäät keltaiset sivut -ohtu-projekti, kesä 2002
Päivämäärä: 31.5.2002
Paikka: TKTL, huone B436
Läsnä:
Eero Hyvönen (asiakkaan edustaja), Kim Viljanen (ohjaaja), Antti Hätinen (puheenjohtaja/projektipäällikkö), Petri Lindgren (sihteeri), Arno Aalto, Merja Jalava, Tuomo Kajava
Kokous alkoi klo 14.00
1. Kävimme läpi ryhmäkokouksessa (31.5.02 klo 12-14) käsitellyt pääkohdat. Yleiseen dokumentointiin ja projektin hallintaan käytämme WikiWikiWeb-työkalua. Versionhallintajärjestelmäksi valitsimme CVS:n. Toteutamme älykkäät keltaiset sivut -projektin Linux ympäristöön käyttäen mm. Tomcat, JSP, Java1.4+httpUnit ja Ant -tekniikoita ja työkaluja. Ontologiat määrittelemme Protege-2000-editorilla.
2. Eero Hyvösen johdolla perehdyimme asiakkaan vaatimusmäärittelyihin. Keskeisimmät ratkaistavat ongelmat ovat ilmoitusten haku tarjotun palvelun/tuotteen perusteella ja ilmoitusten dynaaminen päivittäminen WWW:n välityksellä. Älykkäät keltaiset sivut koostuvat kolmesta pääkomponentista, joita ovat palveluselain, ilmoitustoimitin ja asiakkaiden hallintaväline.
Asiakaskeskustelun pohjalta sovimme tietokannaksi relaatiotietokannan. Mahdollisia vaihtoehtoja relaatiotietokannaksi ovat Oracle tai PostgreSQL. Palveluselaimen toteutuksessa hyödynnämme tkt-laitoksella kehitettyä Ontogator-ohjelmistoa.
Antti ehdotti asiakastarinoiden selvittämiseen käytettäväksi tutkimusta, joka kohdistuisi keltaisten sivujen käyttäjiin. Käytännössä tämä voisi merkitä perehtymistä Keltaiset sivut Oy:ltä saatavaan tutkimusmateriaaliin. Kim Viljanen lupasi selvitellä tätä mahdollisuutta.
Asiakkaalle esitetyistä kysymyksistä selvisi mm., että ilmoitusten haku voidaan toteutetaan niin, ettei suomen kielen taivutuspäätteistä aiheudu ongelmia. Ratkaisuna voisi olla esim. haku puoliluonnollisen kielen lauseilla, joissa avainsanat valittaan valikoista. Tärkeä suunnittelussa huomioon otettava asia on ilmoitusten monikielisyys.
Sovimme asiakkaan kanssa alustavasti aikataulusta.
3. Seuraavaksi meidän on generoitava Keltaiset sivut Oy:n luovuttamasta aineistosta RDF-kuvauksia testausaineistoksi. Lisäksi meidän on etsittävä valmiita toimialakohtaisia luokitteluja ja selvitettävä voimmeko hyödyntää niitä meidän palveluiden ontologian määrittelyssä.
4. Kokouksessa päätettiin seuraavat esitykset:
Ti 04.6
RDF(S), Jena (Petri)
XP-yksikkötestit (Antti)
Pe 07.6
Tomcat, JSP (Tuomo)
Jena+DB+RDF (Arno)
Ti 11.6
Ontologiat (Merja)
Kokous päättyi klo 16.00
17. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Kokous2002-06-04)
Kokous2002-06-04
Aikataulusta
- tuotekhitysympäristö - xEmacs - cvs (ryhmäoikeudet kuntoon) - java 1.3.1 - jUnit - ant - protegee (ok?, versio? 2000-1.7) - tomcat (asennus kesken) - ontogator (ryhmäoikeudet?) - jena - tietokanta - hakemistorakenteen luonnosta //melkki/home/groups/keltsi/cvsroot/ tools/ code/ doc/ //melkki/home/fs/xxx/cvsroot? kullekin oma tomcat? //db.cs.helsinki.fi/home/keltsi/ yhteinen tomcat viimeisen version data viimeisen version binäärit - testit - aloitetaan työkalujen perustoimivuuden testistä, db-jena-tomcat-selain - prototyyppi - ontologia - toimialaluokitus http://www.stat.fi/tk/tt/luokitukset/lk/toimiala_00_keh.html - Esitys:RDFS(Petri)
18. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Kokous2002-06-07)
Kokous2002-06-07
Paikalla:
Kim, Petri, Antti, Arno
Käytiin läpi projektisuunnitelman ensimmäistä versiota. Mitä dokumenttejä laaditaan? Nykyinen dokumentaatio on riittämätön. Pitäisi laatia
Kuinka tuotekehitysympäristön rakentamisiteraatio meni?
Todettiin, että voisi olla hyvä pitää riskianalyysitapaaminen, jossa analysoidaan koko projektiin liittyviä riskejä. Ajateltiin pitää viikottain riskinhallintakokous esimerkiksi perjantaisin.
Tehtiin seuraavan iteraation ositus
Riski Tehtävä
===== =============
Kälisuunnitelma
2 goalien selvittäminen //Antti
3 kälisuunnitelman tekeminen //Antti
DB-Web -yhteys
1 Tomcat-asennus
2 Jena-Tomcat
2 Jena-Oracle
3 RDFScheman teko
3 RDQL opettelu
3 RDB yhteyden luonti
Esimerkkiontologia
3 Protege -käyttö
3 DAML opettelu
Arno piti esityksen Jena:sta.
Todettiin, että viikon lopuksi voisi olla hyvä pitää perjantaisin menetelmän kehittämiskeskustelu, jossa mietitään kuinka ryhmän ja menetelmän toimintaa voisi parantaa. Esimerkiksi huomattiin, että dokumentointikäytännöissä on parantamisen varaa. Koska XP iteraation aikana tulisi luoda hyvälaatuinen, asiakkaalle toimituskelpoinen paketti, myös sen dokumentaation tulisi olla luovutuskelpoista.
19. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Kokous2002-06-11)
Kokous2002-06-11
Klo 14-16 B436 Paikalla:
Antti Tuomo Merja Petri Vilho Raatikka
Käytiin läpi edellisen viikon palaute. Dokumentaatiota voisi parantaa. Projektin nopeutta voisi pienentää. Käytiin uudestaan läpi tämän viikon iteraation tehtävät:
Käligoalit Kälisuunnitelma Tomcat Tomcat+Jena Jena Jena+Oracle Oracle tai PostgreSQL Esimerkkiontologia RDF(S) RDQL
Esimerkkiontologia, käyttöliittymä ja tietokanta/web-yhteys demotaan ensi viikon tiistaina.
Antti sopi tapaamisen Keltaiset Sivut Oy:n Irmeli Rämön kanssa ke klo 14. Vilholle kävi aika hyvin. Antti ja Vilho lähtee Keltaiset Sivut Oy:n yhdessä ke klo 12.30 aluksi syömään ja puhumaan vierailusta ja menetelmästä, ja sitten junalla Kamppiin.
Kim:n mukaan dokumentointia voisi tehdä lisää. Tosiaankin, XP iteraation tulisi tuottaa täysilaatuinen lopputuote, mikä sisältää täydellisen testauksen ja dokumentaation. Jatkossa toiminnan kehittämiseksi pidetään perjantaisin kehityskeskustelu, jossa keskustellaan mm. työn laadusta ja projektin nopeudesta (skoopista) ja muutenkin siitä, kuinka toimintaamme voidaan jatkuvasti kehittää.
Todettiin, että tarvitaan seuraavanlainen dokumentaatio:
- Kuvaus käyttäjistä. Käyttäjäprofiilit ja goalit.
- Käyttöliittymäsuunnitelma.
- Käyttöohje tavallisille käyttäjille
ylläpitäjille
- kuvaus tuotekehitysympäristöstä (käyttöohje jatkokehittäjille)
- Javadoc. Jatkossa tehdään heti riittävän hyvä javadoc.
- Systeemitason arkkitehtuurikuvaus (Dia:lla) + käytetyt design patternit.
- Projektisuunnitelma
- Loppuraportti
Antti palauttaa projektisuunnitelman Turjolle.
Todettiin, että ensisijaisesti projektin dokumentointiin pyritään käyttämään WikiWikiWeb:iä. Ongelmana on kuitenkin WikiWikiWeb-dokumentaation "sarjallistaminen" printattavaksi versioksi, sillä se on hypertextiä. Kuinka WikiWikiWeb suhtautuu projektimappiin, siitä tulee keskustella Turjon ja Kim:n kanssa.
Projektissa käytetään seuraavia kolmea mittaria, jotka pyritään ottamaan käyttöön mahdollisimman pian sekä WikiWikiWebiin? että projektihuoneen seinälle:
Tuntikirjanpito. Seuraa projektin resurssien käyttöä. Tarkoitus on, ettei projektin budjettia ylitetä.
Automaattiset testit. Yksikkötestien läpimenoprosentti kertoo onko koodi rikki vai tuotantokunnossa. Jos läpimenoprosentti on muuta kuin 100%, koodi on rikki. Tavoitearvo on 100%. Yksikkötestien läpimenoprosentti mittaa projektin laatua. Funktionaaliset testit mittaavat projektin edistymistä (skooppi). Sitä mukaan kun funktionaalisten testien läpimenomäärä lisääntyy, projekti etenee.
Projektin nopeus (velocity). Mitataan kuinka paljon saadaan viikossa aikaiseksi. Tarkoitus on mitoittaa projektin nopeus siten, että yhden iteraation aikana saadaan aikaiseksi asiat, joita sen aikana on suunniteltu saatavaksi aikaiseksi. Ideana on, että XP-menetelmä ei koskaan myöhästy ja saa aina valmiiksi suunnitellut tehtävät. Kuinka projektin nopeutta mitataan? Uutena käytäntönä otetaan projektin tehtävien planning gameen tuotekehitysryhmän arvio tehtävän suorittamiseen kuluvasta ajasta (2h, 3pv, 2 viikkoa?) aikaisemman kolmiasteisen riskin lisäksi (0 on jo, 1 tiedän ajan tarkkaan kun olen ennenkin tehnyt, 2 joku haju, 3 ei mitään hajua). Toisinsanoen arvioidaan tehtävän tekemiseen kuluva aika, sekä arvioon liittyvä riski.
Sovittiin, että Tuomo pitää uuden esityksen Tietokantayhteydestä tai Jenan käytöstä tiistaina 25.6.
20. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Kokous2002-06-14)
Kokous2002-06-14
Kokous B436 klo 13-16 Paikalla Antti Merja Petri Tuomo Vilho Raatikka
Tavoitteiden saavuttaminen
Käyttöliittymäsuunnitelmaa ei ole, goaleja ei ole tehty. Käyttöliittymästä esitettiin ajatus continous filter tai autofill -design patternien käytöstä. Mielenkiintoinen kysymys oli mikä oikeastaan on RDF:stä suoritettava hakusana; subjekti, predikaatti vai kenties objekti (vai kaikki) ?
Oracleen saatiin laitettua Jenan tietokantataulut. Jena saatiin asennettua ja kokeiltua, että se toimii. Tomcat on myös asennettu ja todettu toimivaksi. Kuitenkaan minkään työkalun välille ei saatu yhteyttä.
Ontologiaa on mietitty. Esimerkkiontologiaa ei kuitenkaan saatu vielä RDF:ksi, sillä Protege kaatui kun sillä koetti tallentaa RDF:ää.
Lisäksi testattiin ja asennettiin jUnit ja Cactus-testausympäristöjä, sekä rakennettiin Ant-buildympäristöä.
Kaikenkaikkiaan vaikuttaisi, että edelleen iteraation aikana oli liikaa tekemistä. Työmäärän arvioimista varten täytyy ottaa käyttöön työkaluja, jotta jatkossa voidaan tehdä paremmin todellisuutta vastaavia arvioita.
Pariohjelmointi on ollut aluksi vaikeaa, kun asiat ovat uusia. Tiedonsiirto on ollut yksipuolista Antilta muille. Mutta parityöskentelystä on ollut selvästi etua uusien asioiden opettelussa. Vilho ehdotti, että ensi viikon tiistaina klo 14-16 pidettäisiin molempien ryhmien yhteinen esitys ontologiasta.
Todettiin, että jatkossa voisi tuoda CRC-kortit mukaan ainakin iteraation tehtävien suunnitteluun. CRC-korteille (A5-koko) pilkotaan iteraation asiakastarina yksittäisiksi tehtäviksi, joiden kestoa ryhmä arvioi ideaalisina parityöskentelytunteina. Tämän jälkeen arvioidaan myös kuinka hyvä arvio on riskiasteikolla 1..3 (tiedän tarkkaan.. ei mitään hajua).
Lisätään projektisuunnitelmaan uusi toteutunut riski: Linux ympäristö saattaa koska vain lakata toimimasta kesken työskentelyn. Kuinka varautua tähän riskiin? Tänään menetettiin 1,5h työaikaa (no 1h pidettiin enemmän kokousta tosin).
Linux on myös riski, sillä se hidastaa työntekoa. Linux on uusi asia, ja monessa kohtaa myös kovin kömpelö verrattuna Windowsiin (esim leikepöytä, joka ei välttämättä toimi sovelluksesta A sovellukseen B), mikä hidastaa työskentelyä kun joudutaan näpertämään merkityksettömien asioiden kanssa.
Työskentely TKT laitoksella on riski, sillä ATK-ylläpito saattaa koska tahansa poistaa työskentelyjärjestelmän toiminnasta vedoten tietoturva-aukkoihin. Tämä riski täytyy vain hyväksyä (kenties varata pelivaraa?).
Dokumennoinnin kehittäminen
Javadoc ja koodin kommentointi
Mihin koodin kommentointia tarvitaan? Eräs tarve on, että muutkin pystyvät ymmärtämään koodin toiminnan kuin koodin kirjoittaja. XP:ssä tähän tavoitteeseen
pääsemiseen käytetään kahta muuta menetelmää kuin koodin kommentointi; collective code ownership ja yksikkötestit. Ongelmana kommentoinnissa on, että se aiheuttaa ylimääräistä työtä muutenkin kuormitettuun päivärutiiniin. Pelkästään suunnittelu, yksikkötestien tekeminen ja integrointi koodauksen lisäksi ovat hyvin aikaavieviä askeleita. Mikäli tähän joudutaan lisäämään runsaasti ylimääräistä dokumentaatiota, projektin nopeus tulee hidastumaan merkittävästi. Tarkoitus kuitenkin olisi saada jotain aikaiseksikin. Yksi XP:n periaate on Travel Light, jossa viitataan paimentolaisiin, joilla on mukanaan vain teltta ja yksinkertaisia ruuanvalmistusvälineitä. Paimentolaiset liikkuvat kameleiden perässä ja vaihtavat paikkaa usein, he eivät pysty käyttämään vähäisiä resursseja toimintansa ylös kirjoittamiseen, vaan kansantarinat välittyvät suullisena. Vastaavasti XP-projekti kulkee jatkuvasti paikkaansa muuttavien asiakasvaatimusten ja tekniikan perässä, jolloin raskaalla kuormalla ei pysytä muutosten perässä.
Collective Code Ownership tarkoittaa, että kaikki ryhmän jäsenet saavat tehdä muutoksia mihinkä tahansa CVS puun osaan. Vastaavasti vesiputousmallissa työ ositetaan yksittäisille henkilöille, jolloin toiset eivät saa mennä sorkkimaan muiden tekemiä ohjelmanpätkiä ja kaikki muutokset tulee mennä yhden henkilön kautta. Vesiputosmallin perinteisessä tavassa ongelmana on, ettei ole mitään takuuta siitä että muun henkilön tekemän muutoksen jälkeen ohjelma toimisi enää samalla lailla kuin se toimi ennen muutosta. XP:ssä ohjelman toiminnallisuus kuitenkin varmistetaan automaattisilla testeillä, jolloin refaktoroinnin jälkeen voidaan aina tietää toimiiko koodi samalla tavalla kuin se toimi ennen muutosta siitä menevätkö testit läpi vai ei.
Koodin yhteisomistus asettaa kuitenkin tiettyjä vaatimuksia sille minkälaista koodia kirjoitetaan. Jos Maijan mielestä {:tä edeltää välilyönti ja Matin mielestä ei, ongelmaksi syntyy minkälaista koodaustyyliä käytetään. Pahimmassa tapauksessa Matti käy illalla poistamassa välilyönnit illalla, ja Maija lisää ne takaisin aamulla. Koodin kirjoittamista varten täytyy siis sopia yhteinen Coding Standard, joka voi olla mikä tahansa mistä päästään yhteisymmärrykseen. Se on hyvä dokumentoida ja yhteneväinen tyyli ja nimeämiskäytännöt auttavat myös koodin luettavuudessa suuresti. Meidän tyylistandardiksi on ehdotettu Sun:n Java Coding Standard:ia ilman Javadoc:ia, mistä joku voisi pitää esitelmänkin.
Välttämättä kaikkea kommentointia ei tarvitse jättää tekemättä. Kuitenkin on täysin turhaa käyttää aikaa kommentoinnin käyttämiseen ryhmän sisäisenä kommunikointikeinona, kun työskentelemme yhteisessä tilassa ja voimme vaihtaa tietoa helpommin suullisesti kuin kirjoitetussa muodossa.
Mitä tulee ryhmän ulkoiseen kommunikointiin, niin automaattiset testit näyttelevät myös tärkeää osaa siinä mitä koodi oikeastaan on. Ne periaatteessa määrittelevät koodin ulkoisen käyttäytymisen. Tällöin koodin sisäistä rakennetta voidaan muuttaa tarvittaessa (liikkua kamelien perässä) refaktoroimalla sitä. Testien ansiosta voidaan edelleen olla varmoja sen ulkoisen toiminnan muuttumattomuudesta. Koska muutos ja refaktorointi on jatkuvaa, on äärimmäisen tärkeää XP-menetelmässä että muutoksen tekeminen on halpaa. Tällöin ylimääräinen kommentointi puukottaa menetelmää vakavasti. Lisäksi koodin rakenteen kuvaaminen on lähes mieletöntä, sillä se periaatteessa muuttuu viikoittain. Ja sen on tarkoituskin muuttua. Yksikkötestien avulla voidaan kuitenkin määritellä koodinpalasen skooppi, jonka jälkeen etsitään yksinkertaisin mahdollinen toteutus. Useimmissa tapauksissa ratkaisu ei toivonmukaan ole monimutkainen (muuten epäonnistutaan yksinkertaisuus-periaatteessa).
Jos kooditason kommentointi jätetään pois, sen sijaan edelleen kannatan systeemitason arkkitehtuurikuvausten tekemistä design patternien avulla. Pienten koodikikkareiden kuvaamisen sijasta myös myöhemmille koodin käyttäjille (ja meille itsellemme) on hyödyllisempää piirtää yleiskuva järjestelmästä ja sen suunnitteluperiaatteista. Systeemiarkkitehtuurin kuvaustavaksi ehdotettiin neljää työkalua; Poseidon+ArgoUML, xfig, dia ja pelkkä paperi/fläppitaulu. Työkalua ei kuitenkaan päätetty vieläkään.
Kaikki ylläolevat perustelut puoltavat sitä, että koodin tarpeettomasta kommentoinnista ja javadocista pidättäydytään.
Vilhon mielestä kommentteja ja javadoc:ia tarvitaan.
Projektisuunnitelma on nykyään ainoastaan WikiWikiWebiss?ä.
Päivemmällä päätettiin että keskiviikkoisin voitaisiin 10 sijasta tulla 9:ltä paikalle, jolloin kaikkina päivinä tullaan 9:ksi.
21. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esitelm%E4aiheet)
Esitelmäaiheet
Java Coding Standard
Design Pattern: Facade
Design Pattern: Strategy
Design Pattern: Abstract Factory
....
22. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Tuntikirjanpito)
Tuntikirjanpito
23. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Antti)
Antti
Vk 22
Vk 23
Vk 24
Vk 25
Vk 26
24. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Merja)
Merja
Vk 22
Vk 23
Vk 24
Vk 25
25. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Arno)
Arno
26. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Petri)
Petri
Vk 22
Yht. = 11h
Vk 23
Yht. = 25h
Vk 24
Yht. = 22h
Vk 25
Yht. = 17h
Vk 26
27. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Tuomo)
Tuomo
Vk 22
Vk 23
---
Vk 24
---
Vk 25
---
28. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Varattuna)
Varattuna
varattuna (ei voi osallistua projektiin) x = koko päivä a = aamupäivä i = iltapäivä
3.6. vko 23
ma ti ke to pe
Antti
Merja x x
Arno
Petri
Tuomo
10.6. vko 24
ma ti ke to pe
Antti
Merja x
Arno x x x x x
Petri x
Tuomo
17.6. vko 25
ma ti ke to
Antti x x
Merja
Arno x x x x
Petri
Tuomo
24.6. vko 26
ma ti ke to pe
Antti
Merja
Arno
Petri
Tuomo
1.7. vko 27
ma ti ke to pe
Antti
Merja
Arno
Petri x x
Tuomo x
8.7. vko 28
ma ti ke to pe
Antti
Merja
Arno
Petri
Tuomo x
15.7. vko 29
ma ti ke to pe
Antti
Merja
Arno
Petri
Tuomo x
22.7. vko 30
ma ti ke to pe
Antti
Merja
Arno
Petri
Tuomo
29.7. vko 31
ma ti ke to pe
Antti
Merja x x x
Arno
Petri
Tuomo
5.8. vko 32
ma ti ke to pe
Antti
Merja
Arno
Petri
Tuomo
12.8. vko 33
ma ti ke to pe
Antti
Merja
Arno x x x x a
Petri
Tuomo
19.8. vko 34
ma ti ke to pe
Antti
Merja
Arno a x x a
Petri
Tuomo
26.8. vko 35
ma ti ke to pe
Antti
Merja
Arno a x x a
Petri
Tuomo
29. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Laatu%20ja%20mittarit)
Laatu ja mittarit
Laatu
Projektin laatua kehitetään perjantain kokouksessa pidettävässä kehityskeskustelussa. Siinä keskustellaan minkälaista laatua on saatu aikaiseksi verrattuna tavoitteisiin, projektin nopeudesta, asetetaan uusia tavoitteita ja keskustellaan kuinka toimintaa voidaan jatkuvasti parantaa.
Työn laatu varmistetaan tekemällä automaattisia testejä kaikesta ohjelmakoodista ennen kuin itse koodia kirjoitetaan. Laaditaan sekä funktionaalisia testejä testaamaan iteraatioiden tehtävien valmistumista ja toimimista sekä yksikkötestejä varmistamaan yksittäisten luokkien toimintaa.
Mittarit
Projektissa käytetään seuraavia kolmea mittaria, jotka pyritään ottamaan käyttöön mahdollisimman pian sekä WikiWikiWebiin? että projektihuoneen seinälle:
30. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?ReleasePlan)
ReleasePlan
Julkaisusuunnitelmassa esitetään koko projektin toteutussuunnitelma, jonka jälkeen yksittäiset iteraatiot kuvataan tarkemmin. Jokaisen iteraation jälkeen ryhmän tulisi pystyä julkaisemaan palautuskelpoinen versio, johon on lisätty iteraation aikana valmistuneet ominaisuudet. Oleellista on kuitenkin, että julkaisun laatu on lopullista ja hyvää. Toisinsanoen iteraation aikana laaditaan automaattiset testit, dokumentaatio sekä integroidaan lisäykset aikaisempaan koodiin.
Iteraatio Kesto(vk) Riski --------- --------- ----- Tuotekehitysympäristön rakentaminen [31.] 2 11/5 Ensimmäinen Demo [32.] 2 10/5 Iteraatio III 2 Iteraatio IV 2 Toinen Demo 2 Iteraatio VI 2 Työn palautus [36.] 1
Riski on luku välillä 1..3 ja mitataan arvioimalla tuotekehitysryhmän mielipidettä kuinka hyvin he osaavat arvioida kuinka kauan iteraation suorittamiseen menee aikaa.
31. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Tuotekehitysymp%E4rist%F6n%20rakentaminen)
Tuotekehitysympäristön rakentaminen
Rakennetaan CVS-puu ja tiedostorakenne, johon laitetaan eritellen projektin lähdekoodi ja työkalut. Asennetaan ja konfiguroidaan työkalut, sekä kokeillaan niiden käyttö.
32. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Ensimm%E4inen%20Demo)
Ensimmäinen Demo
Laaditaan paperiprototyyppi käyttöliittymästä. Tehdään prototyyppiyhteys tietokannasta web-näkymään. Jena/RDF(S)-prototyyppi. Esimerkkiontologia.
Valmis Tehtävä
--- -------
X Ensimmäinen Demo - Oracle
X Ensimmäinen Demo - Jena
X Ensimmäinen Demo - Tomcat
Ensimmäinen Demo - Oracle ja Jena [33.]
Ensimmäinen Demo - Ontologia [34.]
Ensimmäinen Demo - Jena ja Ontologia [35.]
33. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Ensimm%E4inen%20Demo%20-%20Oracle%20ja%20Jena)
Ensimmäinen Demo - Oracle ja Jena
Oracle ja Jena
Nyt kun Jena-tietokanta on löyty sisään, koetetaan tehdä jUnit -testi, joka laittaa tietokantaan oikeaa RDF:ää. Lisäksi testiohjelma hakee testi-RDF:n. Mahdollisimman simppeli RDF-kuvaus (yksi rivi?) riittää.
Kestoarvio: 10h
Riski: 1,5
34. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Ensimm%E4inen%20Demo%20-%20Ontologia)
Ensimmäinen Demo - Ontologia
Ontologia
Laaditaan _yksinkertainen_ (5-10 luokkaa esim?) esimerkkiontologia. Opetellaan Protegen käyttö ja tehdään siitä RDF-kuvaus. Jos Protege ei toimi, niin tehdään vähän simppelimpi käsin.
Kestoarvio: 6 työpäivää (2 viikkoa)
Riski: 2
35. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Ensimm%E4inen%20Demo%20-%20Jena%20ja%20Ontologia)
Ensimmäinen Demo - Jena ja Ontologia
Jena ja Ontologia
Syötetään aiemmin laadittu esimerkkiontologia Jena-testiohjelmalle, joka tallettaa sen tietokantaan.
Kestoarvio: ?
Riski: ?
36. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Ty%F6n%20palautus)
Työn palautus
Laaditaan loppuraportti. Laaditaan käyttöohje. Printataan materiaali ja dokumentaatio kurssimappiin. Demotaan tuote asiakkaalle että Keltaiset Sivut Oy / Irmeli Rämö.
37. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Aikataulu)
Aikataulu
Pe 18.10. Tietoenator-demo Ma-Ti 21-22.10. XML-Finland seminaari
Esimerkki viikko-ohjelma [51.]
ReleasePlan [30.]
38. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?vk%2023)
vk 23
Tiistai 4.6.
klo 9 Ryhmä tapaa TKTL ala-aulassa. Etsitään sopiva työskentelytila parikoodaukselle. Pidetään stand up meeting aiheena miten aletaan pystyttämään tuotekehitysympäristöä. Lisäaiheena tutkitaan tarkasti ryhmäläisten henkilökohtaisia aikatauluja. Kun ympäristö on pystyssä, Antti demoaa kuinka jUnit/Java 1.4 -testejä tehdään käytännössä. Käydään syömässä ennen kokousta klo 14.
klo 14.15 Kokous B436. Katso Esityslista2002-06-04 [39.] .
Torstai 6.6.
Klo 10. Ryhmä tapaa työskentelytilassa. Stand up meeting. Pystytetään * tuotekehitysympäristöä.
Klo 13. Käydään syömässä.
Klo 16. Lähdetään kotiin.
Perjantai 7.6.
Klo 9. Ryhmä tapaa työskentelytilassa. Stand up meeting.
~Klo 13.30. Mennään syömään.
Klo 14.15. Kokous B436. Katso Esityslista2002-06-07 [40.] .
39. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-06-04)
Esityslista2002-06-04
Esityslista:
Muuta:
40. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-06-07)
Esityslista2002-06-07
Esityslista:
41. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?vk%2024)
vk 24
Maanantai 10.6.
Antti laittaa infoa kokouksesta (paikka, aika, esityslista) Kim:ä tuuravalle Vilho Raatikalle (Vilho.Raatikka@cs.helsinki.fi)
Tiistai 11.6.
Klo 9.00 Ryhmä tapaa työskentelytilassa. Stand up meeting.
Klo ~13.30 Käydään syömässä.
klo 14.15 Kokous B436. Katso Esityslista2002-06-11 [42.] .
Klo 16. Lähdetään kotiin.
Keskiviikko 12.6.
Klo 9. Ryhmä tapaa työskentelytilassa. Stand up meeting.
Klo 12.30 Antti lähtee Vilhon kanssa syömään / puhumaan
Klo 13. Käydään syömässä.
Klo 14.00 Tapaaminen Keltaiset Sivut Oy / Irmeli Rämö //Antti & Vilho
Klo 15. Lähdetään kotiin.
Perjantai 14.6.
Klo 9. Ryhmä tapaa työskentelytilassa. Stand up meeting.
~Klo 13.30. Mennään syömään.
Klo 14.15. Kokous B436. Katso Esityslista2002-06-14 [43.] .
Klo 16. Lähdetään kotiin.
Muuta: Vilho Raatikka (vilho.raatikka@cs.helsinki.fi; http://www.cs.helsinki.fi/vilho.raatikka/) tuuraa Kimiä. Pistäkää hänelle mailitse tietoa tiistain ja perjantain kokouksista (kokousta edeltävänä päivänä). Paikka, aika, sisältö, jne. (Kim)
42. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-06-11)
Esityslista2002-06-11
Esityslista:
43. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-06-14)
Esityslista2002-06-14
- menetelmä - dokumentointi - onko javadocin tekeminen fiksua? - kuinka tehdä käyttöohje? ehdotus: kälisuunnitelman skenaariokuvat - mitä laitetaan projektikansioon? - systeemitason suunnitteludokkarit & UML? ehdotus1: poseidon ehdotus2: paperi - projektisuunnitelma open officena & webbiin ? ehdotus: vain yksi versio - CRC -kortit ja käyttäjätarinat? - laatu - kokouskäytäntö - projektinhallinta
44. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?vk%2025)
vk 25
Tiistai 18.6.
Klo 9.00 Ryhmä tapaa työskentelytilassa. Stand up meeting. Klo ~13.30 Käydään syömässä. Klo 14.00 Yhteysdemokokous meedio-ryhmän kanssa kahvihuoneen vieressä. Klo 15.15 Kokous B436. Katso Esityslista2002-06-18 [45.] . Klo 16. Lähdetään kotiin.
Keskiviikko 19.6.
Klo 9. Ryhmä tapaa työskentelytilassa. Stand up meeting. Klo 13. Käydään syömässä. Klo 15. Lähdetään kotiin.
Torstai 20.6.
Juhannuksen vietto
Perjantai 21.6.
Juhannuksen vietto
Muuta:
45. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-06-18)
Esityslista2002-06-18
klo 15.15 siirrytään D436:een
46. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?vk%2026)
vk 26
Ma 24.6.
10.00 Semantic Web - seminaari A216
Antti laatii tiistain kokouksen esityslistan ja postittaa sen.
Klo 12. Käydään syömässä.
Klo 12.30. Ryhmä tapaa työskentelytilassa. Stand up meeting.
Klo 16. Lähdetään kotiin.
Ti 25.6.
Klo 9.00 Ryhmä tapaa työskentelytilassa. Stand up meeting. Klo ~13.30 Käydään syömässä. Klo 14.00!! Kokous B436. Katso Esityslista2002-06-25 [47.] . Klo 15.30 Lähdetään kotiin.
To 27.6.
Siirretty maanantaiksi.
Pe 28.6.
Klo 9. Ryhmä tapaa työskentelytilassa. Stand up meeting. ~Klo 13.30. Mennään syömään. Klo 14.00 Kokous B436. Katso Esityslista2002-06-28 [48.] . Klo 15.30 Lähdetään kotiin.
Muuta:
47. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-06-25)
Esityslista2002-06-25
- projektisuunnitelma - loppusyksyn seminaarit - rästituntien tasaaminen
48. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-06-28)
Esityslista2002-06-28
- menetelmä - dokumentointi - kokoukset - projektinhallinta
49. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?vk%2027)
vk 27
Ti 2.7. Klo 9.00 Ryhmä tapaa työskentelytilassa. Stand up meeting. Klo ~13.30 Käydään syömässä. Klo 14.00!! Kokous B436. Katso Esityslista2002-07-02 [50.] . Klo 15.30 Lähdetään kotiin.
To 4.7. Klo 9.00 Ryhmä tapaa työskentelytilassa. Stand up meeting. Klo ~13.30 Käydään syömässä. Klo 15.00 Lähdetään kotiin.
Pe 5.7. Klo 9. Ryhmä tapaa työskentelytilassa. Stand up meeting. ~Klo 13.30. Mennään syömään. Klo 14.00 Kokous B436. Katso Esityslista2002-07-02 [50.] . Klo 15.30 Lähdetään kotiin.
Muuta:
50. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-07-02)
Esityslista2002-07-02
- Lokakuun seminaarit ja esitykset
50. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esityslista2002-07-02)
51. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esimerkki%20viikko-ohjelma)
Esimerkki viikko-ohjelma
Ma
Antti laatii tiistain kokouksen esityslistan ja postittaa sen.
Ti
09.00 Tavataan D327
Stand up meeting - jaetaan päivän tehtävät ja parit
09.15 Aloitetaan koodaamaan
Tehdään yksikkötestit
Antti laske edellisen viikon tuntikirjanpito yhteen
Antti tekee funktionaaliset testit tehtäville
13.30 Käydään syömässä
14.15 Kokous B436 Esimerkki tiistain kokousohjelma [52.]
16.00 Lähdetään kotiin
Ke
Varapäivä
To
09.00 Tavataan D327
Stand up meeting - jaetaan päivän tehtävät ja parit
09.15 Aloitetaan koodaamaan
Tehdään yksikkötestit
Suunnitellaan
Refaktoroidaan
Antti laske edellisen viikon tuntikirjanpito yhteen
Antti tekee funktionaaliset testit tehtäville
13.00 Käydään syömässä
15.00 Lähdetään kotiin
Pe
09.00 Tavataan D327
Stand up meeting - jaetaan päivän tehtävät ja parit
09.15 Aloitetaan koodaamaan
Tehdään yksikkötestit
Antti laske edellisen viikon tuntikirjanpito yhteen
Antti tekee funktionaaliset testit tehtäville
13.30 Käydään syömässä
14.15 Kokous B436 Esimerkki perjantain kokousohjelma [53.]
16.00 Lähdetään kotiin
52. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esimerkki%20tiistain%20kokousohjelma)
Esimerkki tiistain kokousohjelma
53. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Esimerkki%20perjantain%20kokousohjelma)
Esimerkki perjantain kokousohjelma
- menetelmä - dokumentointi - laatu - kokouskäytäntö - projektinhallinta
30. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?ReleasePlan)
54. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Resurssit)
Resurssit
Käytössä olevat resurssit
Projektin käytössä on 5 henkilöä, joille maksetaan 6ov = 6 x 40h=240h. Käytössä on siis 5 x 240h = 1200h työtuntia. Projekti voi käyttää Helsingin yliopiston tietojenkäsittelytieteenlaitoksen tiloja ja laitteita. Projekti työskentelee pääasiassa luokassa D327.
Projektin organisointi
Antti Hätinen toimii projektin projektipäällikkönä ja interaktiosuunnittelijana, ja vastaa siten menetelmästä, käyttöliittymästä sekä projektin yleisesti edistymisestä.
Tuomo Kajava, Merja Jalava, Arno Aalto ja Petri Lindgren muodostavat kaksi pariohjelmointiparia, jotka kolme kertaa viikossa kokoontuvat sovittuina aikoina ohjelmoimaan menetelmän mukaisesti.
Antti tuntee hyvin XP ja käyttöliittymäsuunnittelumenetelmät, J2EE, XML, Oracle ja PostgreSQL -ympäristöt web-kehitykseen. Lisäksi työkalut kuten CVS, Ant, jUnit, Cactus ja Tomcat ovat ennestään tuttuja.
Petri tutustui Semantic Web-tekniikoihin Tieteellisen kirjoittamisen kurssin tutkielmassaan. Petri on käyttänyt CVS:ää aikaisemminkin.
Tuomo on tehnyt tietokanta ja web-sovellutuksia Microsoftin ASP/IIS-ympäristössä.
Merja ja Arno lähtevät innokkaina kohti projektin tarjoamia uusia mielenkiintoisia haasteita.
Projektin asiakkaana toimii Eero Hyvönen.
Projektin ohjaajana toimii Kim Viljanen.
Projektin vastuuhenkilö on Turjo Tuohiniemi.
55. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Ty%F6kalut)
Työkalut
Projekti tehdään TKT laitoksen Linux-ympäristössä.
Projektissa käytetyt työkalut:
Kääntäjä Java SDK & JRE versio 1.3.1 (laitoksen oletusasennus)
Versionhallinta CVS versio 1.11.1p1 +komentoriviclient
Build-työkalu Ant versio 1.4.1
editori xEmacs versio 21.1 (patch 14) (laitoksen oletusasennus)
testityökalu jUnit versio 3.7
Servlet-testiympäristö Cactus versio 1.3-13 jUnit:n laajennus
Ontologiaeditori Protege versio 1.7
Dokumentoinnin hallinta WikiWikiWeb phpWiki versio 1.2.2 asennettu Antin omalle koneelle
Semantic Web framework Jena versio 1.4.0
Tietokanta Oracle versio 9i (laitoksen oletusasennus)
Servlet engine Tomcat versio 4.0.3
56. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Riskit)
Riskit
Windows-ympäristö lakkautetaan -> ei voida työskennellä Windows kaatuu -> työtä menetetään => Käytetään Linux-ympäristöä
Projektikuri höltyy ja palataan perinteisiin menetelmiin. -> Projektin tavoitteita menetelmän suhteen ei saavuteta. Aikaa tuhlaantuu. Mitään ei saada aikaiseksi. =>
Yhteistä koodausstandardia ei saada sovittua. Aika kuluu koodin ulkoasun kanssa leikkimiseen. Riidellään välilyöntien paikasta. Huonontaa ilmapiiriä. => pyritään alusta alkaen sopimaan Sun standardin mukaisesta koodausstandardista.
Goaleja ei saada selvitettyä. Projektin määrittely on epämääräinen. => Goalien tekeminen on ykkösprioriteetissä
Ei tehdä testejä. Uusien iteraatioiden tekeminen vaikeutuu huomattavasti. => Opetetaan testien tekeminen aikaisin. Mitataan testien tekemistä ja läpimenoprosenttia. Laaditaan funktionaaliset testit testaaman asiakastarinoiden toteutumista.
Projektipäällikön aika loppuu. Goaleja ja asiakastarinoita ei saada tehtyä. Kokousten esityslistat jäävät tekemättä. Kaikki tapahtuu ad hoc. => lisää vastuuta itse tiimille
Projektiryhmän jäsen sairastuu eikä pääse paikalle. => Käytetään pariohjelmointia, ei ongelmaa koska kaiken tiedon pitäisi välittyä koko ryhmälle. Näin menetetään vain pieni osa työstä.
Projektipäällikkö sairastuu eikä pääse paikalle. Ryhmä joutuu toimimaan ilman ohjausta. => Harjoitellaan XP-rutiinit riittävän itseohjautuviksi, ja tehdään yksi versio projektin loppuun saakka ulottuvasta iteraatiosuunnitelmasta sisältöineen.
57. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?L%E4hteet)
Lähteet
5. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Beck00)
13. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Cooper00)
9. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?H%E4tinen02)
6. (http://www.avatars.fi/~pharazon/ohtu/phpwiki-1.2.2/index.php?Laakso01)