Edistymisraportti v. T4 (Toteutus 4) Päivitetty 15.3.2001 klo 18:13
2 (8) Sisällys 1 PROJEKTIN TILA...3 2 SUORITETUT TEHTÄVÄT...6 3 KÄYTETYT MENETELMÄT...7 4 ONGELMAT...8 EDISTYMISRAPORTTI 2
3 (8) 1. Projektin tila Vaiheen aikana keskityttiin testaukseen ja sovelluskehyksen toiminnan parantamiseen. Sovelluskehyksen optimoinnin seurauksena suorituskyky parani rutkasti. Lisää toiminnallisuutta ei sovelluskehykseen varsinaisesti lisätty. Sovelluskehikko on bugien metsästystä vaille valmis. Projektisuunnitelmassa esitetyistä TOP10 tavoitteista tavoitteet 1, 2, 3, 5, 6, 8 ja 10 ovat projektiryhmän arvion mukaan täytetty. Sovelluskehikon nopeus, tavoite 6, suorastaan yllätti. Muutamalla pienellä optimoinnilla saavutettiin Oracle-tietokantaa käyttäen 100:lla yhtäaikaisella käyttäjällä noin 1 sekunnin keskimääräinen vasteaika autentikoinnille. Komentojen reititykseen ja oikeuksien tarkistukseen kuluva aika alittaa Javan tarjoaman kellon tarkkuuden, mikä on oikein riittävä tehokkuus. Tavoitteesta 7, sovelluskehikon helppokäyttöisyydestä, on hieman epäselvyyttä. Sovelluskehikon käyttö on Apachemainen, eli pitkälle pääsee konfiguraatioita muuttamalla muutamasta tekstitiedostosta. Ryhmän mielestä käyttö on varsin helppoa, mutta todelliset käyttötilanteet tulevaisuudessa näyttävät asian todellisen laidan. Tomas, joka on töissä asiakkaalla, sanoo, että hän aikoo käyttää sovelluskehikkoa tulevissa projekteissa. TOP10 tavoitteet 4 ja 9 perustuvat asiakkaan arvioon, joten niiden täyttymistä ei voida luotettavasti arvioida, mutta ryhmän käsitys tavoitteesta 4 (modulaarisuus) on, että se on saavutettu selkeästi. Sovelluskehikosta on miltei mikä tahansa palanen vaihdettavissa toiseen, kunhan rajapinnat toteutetaan. Timon vähäisen panoksen vuoksi projektiryhmä päätti, ettei Timolle enää allokoida tehtäviä, ja Timoa voidaan pitää näin ollen ryhmästä erotettuna. Timo itse ei asiasta ollut siinä mielessä innoissaan, että onhan hän projektin alussa siihen käyttänyt aikaa, mutta ymmärtää kuitenkin tilanteen. Eihän ole reilua, että yksi ryhmän jäsen saa vapaaratsastamalla opintoviikot muiden työstä, mahdollisesti arvosanaa laskien. Timon poistuminen projektiryhmästä tässä vaiheessa ei varsinaisesti aiheuta ongelmaa, sillä onhan varsinainen työ jo tehty. Timon vähäinen panos projektin aikana on kuitenkin johtanut huomattavasti alkuperäisistä suunnitelmista tingittyyn demosovellukseen. Tämä ei ole ongelma, sillä demosovellus ei ole asiakkaalle merkittävä osa kokonaisuutta. Projektissa oli varauduttu siihen, että tarvittaessa demosovelluksesta voidaan tinkiä, eikä varsinaisen sovelluskehyksen suhteen tarvitse tinkiä, ja näin näyttää myös käyvän. EDISTYMISRAPORTTI 3
4 (8) Kuva 1Vaiheen työmäärän jakautuminen henkilöittäin Kuva 2 Vaiheen työmäärän jakautuminen työlajeittain Kuva 3 Vaiheelle suunniteltu työmäärä Kuva 4 Vaiheen tehtävät EDISTYMISRAPORTTI 4
5 (8) Kuva 6 Projektin työmäärän jakautuminen henkilöittäin Kuva 5 Projektin työmäärän jakautuminen työlajeittain Kuva 7Projektin kokonaistyömäärät Kuva 8 Projektin suunniteltu työmäärä EDISTYMISRAPORTTI 5
6 (8) 2. Suoritetut tehtävät Projektiryhmä on vaiheen aikana? päivittänyt testaussuunnitelman? päivittänyt riskienhallintasuunnitelman? päivittänyt sovelluskehikon teknisen määrittelyn? päivittänyt projektisuunnitelman? optimoinut sovelluskehikkoa? suorittanut testausta, muutama bugikin korjattiin? implementoinut LDAP-rajapinnan loppuun asti? kirjoittanut alustavan käyttöohjeen sovelluskehikkoon EDISTYMISRAPORTTI 6
7 (8) 3. Käytetyt menetelmät? Näytä mulle menetelmä Projektityöskentelyn takapainoisuuden poistamiseksi päätettiin kokeilla tapaa, että vaiheen sisälle asetetaan sisäiset virstanpylväät jonka päätteeksi tuotokset tulee tuoda näytille projektipalaveriin. Menetelmä ei toiminut täydellisesti, mutta sovitut asiat tuli tehtyä, mutta ei aivan ajallaan. Parannusta kuitenkin oli havaittavissa.? RiskIt riskienhallintamenetelmä RiskIt menetelmä vaikuttaa hieman raskaalta tämän kokoiseen projektiin. Tämän kokoisessa projektissa riskejä ei ole paljoa, ja suuri osa tunnistettavista riskeistä on merkitykseltään mitättömiä, tai niihin ei voida varsinaisesti reagoida. Osa riskeistä ilmenee täysin satunnaisesti, jolloin RiskIt tarjoaa valmiiksi mietityn ratkaisun ongelmaan. Riskienhallintaan käytetty aika ei kuitenkaan vastaa siitä saatavia hyötyjä. Tämän kokoisessa projektissa riskit ovat helppoja tunnistaa ja hoidella niiden ilmetessäkin, eikä niiden hallinta tarvitse suurta esivalmistelua. Tämän vuoksi projektin johdossa ei RiskIt menetelmää ole aivan orjallisesti noudatettu, vaan sen rinnalla on pyöritetty joustavaa MUTUpohjaista menetelmää. RiskIt on kuitenkin tuonut riskienhallintaan hieman näkemystä siitä, että mitä voi tapahtua, ja mihin projektijohdon tulee kiinnittää huomiota projektin kuluessa. Etukäteen pohdituista ratkaisumalleista ei sinänsä ole ollut hyötyä, ja osaa toteutuneista riskeistä ei ole osattu etukäteen tunnistaa, kuten T2 ja T3-vaiheiden aikana vastaan tulleet lisenssiongelmat. EDISTYMISRAPORTTI 7
8 (8) 4. Ongelmat Kuluneen vaiheen aikana esiintyi merkittävän paljon ongelmia eri palvelinohjelmistojen kanssa. Netscape Directory Server osoittautui liian hankalaksi asennettavaksi ja sen tarjoama konsoliohjelma oli epävakaa käytettäessä. Lisäksi Netscapen tarjoama käyttäjätietorakenne oli liian kankea ja huonosti konfiguroitava. Tästä syystä siirryttiin käyttämään IBM:n SecureWay Directory -palvelinta. SecureWay osoittautui huomattavasti geneerisemmäksi, mutta sen tarjoamat hallintatyökalut olivat vaikeita käyttää. Hallintatyökalu ilmoitti usean toiminnon yhteydessä sisäisestä virheestä, eikä lisäinformaatiota tarjottu. Tästä oli erittäin hankalaa päätellä mistä virhe johtui. Lisäksi salasanakenttä osoittautui vaikeaksi käsiteltäväksi JNDI-rajapinnan kautta. Testauksen helpottamiseksi konfiguroitiin toinenkin instanssi Oraclesta. Oraclen konfiguroiminnen kuitenkin osoittautui vaikeaksi ja siihen kului ylimääräistä aikaa. Tämän lisäksi myös testikoneena käytetty kannetava aiheutti ongelmia kaatuilemalla. EDISTYMISRAPORTTI 8