PPT Loppukatselmointi

Esitys aiheesta: "PPT Loppukatselmointi"— Esityksen transkriptio:

1 PPT Loppukatselmointi 7.4.2004
T Projektikatselmus PPT Loppukatselmointi

2 Agenda IOBASE-palvelun esittely (20 min) Projektin arviointi (15 min)
Johdanto palveluun (5) Palvelun demo (15) Projektin arviointi (15 min) LU-vaiheen tavoitteiden saavuttaminen (2) Projektin eteneminen (3) Jälkilaskelmat (4) Tulokset (2) Työmenetelmät ja työkalut (2) Oppiminen (1) Kurssipalaute (1) Kommentteja ja kysymyksiä (5 min)

3 Johdanto palveluun IOBASE (Information Out of the Big Automation SystEm) –projektin tarkoituksena tuottaa järjestelmä, jolla kerätään automaatiodataa useasta eri tietokannasta ja tämä tieto tarjotaan käyttäjille web-liittymän kautta. Vastaavaa palvelua ei ole aiemmin tehty. Yksittäisten osien toteuttaminen ei ollut järkevää, vaan haluttiin tuottaa palvelusta järkevä ja jatkokehitettävä prototyyppi. Palvelun laajuus haasteena. Palvelun vaatimia osia ovat: Tietokanta (tehty) Tiedonsiirto kantojen välillä (tehty) WWW-sivujen luonti kannan tiedoista Kulutusseurantakaaviot (tehty) Raportit (ei ehditty, kanta tukee) Web-käyttöliittymät sekä loppukäyttäjälle eli ylläpitäjälle (tehty) Eräajoarkkitehtuuri (alustettu) Tietokannan koon hallinta eli tiedon pakkaaminen väliajoin (alustettu)

4 Johdanto palveluun – IOBASE-järjestelmä

5 Demo: Palvelun käyttö verkon yli
Sisältää tietojen siirron IOBASE-kannan ja käyttöliittymien välillä Kanta ja www-palvelin sijaitsevat fyysisesti asiakkaan tiloissa Kaikki ruudulla näytettävät kaaviot generoidaan ”lennossa” kannan tiedoista Käyttäjän syöttämät tiedot tallennetaan kantaan Demo tapahtuu Internet:in yli eli vastaa todellista käyttötilannetta Kaikkia toimintoja ei ehditä esittämään. Seuraavat esitellään: Loppukäyttäjän käyttöliittymä: Palvelun yleisesittely Kulutusseuranta Ylläpitäjän käyttöliittymä (hallinnointityökalu): Etusivu Käyttäjien hallinta Kiinteistöjen hallinta Luovutus-CD

6 LU-vaiheen tavoitteiden saavuttaminen
Tavoite 1: Varmistaa palvelun laatu lopputesteillä OK, vaiheen alussa tehtiin Build 3.0, jossa havaitut virheet korjattiin tämän jälkeen build 3.1:ksi. Tälle suoritettiin vastaavat testit regressiotestauksena. Tavoite 2: Viimeistellä tekninen määrittely ja muu luovutettava dokumentaatio OK, Tekniselle määrittelylle tehty vielä staattinen testaus Tavoite 3: Kirjoitetaan loppuraportti OK Tavoite 4: Asiakaskoulutuksen läpivienti OK, tuote tehty asiakkaan tiloissa ja palvelussa käytönaikainen ohje, joten ei tarvetta enää itse palvelun käytön kouluttamiseen. Koulutettiin SQL EnterPrise Manager:in käyttöä kannan ylläpidossa sekä yhtä asiakkaan edustajaa ohjelmakooditasolla, jotta jatkokehittäminen olisi helpompaa. Tavoite 5: Valmistetaan luovutus-CD ja siihen tarvittavat skriptit

7 Projektin eteneminen (1)
PS-vaihe Ryhmän muodostaminen ja käytännöistä sopiminen Asiakkaaseen tutustuminen Mittavan vaatimusmäärittelyn tekeminen asiakkaan kielellä (Use Case:t) Riskienhallinnan aloittaminen Haasteena laaja projekti: Piti tunnistaa asiakkaan kannalta tärkeimmät palvelun osat ja sopia ainoastaan niiden toteuttamisesta Resurssien maksimiraja nostettiin 210h/jäsen I1-vaihe Tehostettu ajankäyttöä Tavoitteet ylitettiin: kanta valmis loppukäyttäjän käyttöliittymästä 2 versiota hallinnointityökalun paperiversio Tiedonsiirto kantojen välillä toimi testitilanteessa Tekninen määrittely aloitettiin Testausta vain moduulitasolla Ongelmana usean yhteistyötahon (3) mukana pitäminen

8 Projektin eteneminen (2)
I2-vaihe Epävarmuus jäsenten aikatauluista I3-vaiheessa, joten päätettiin joululoman jälkeen tehdä niin paljon toiminnallisuuksia kuin mahdollista. Heuristinen analyysi loppukäyttäjän käyttöliittymälle Tavoitteet ylitettiin: Tiedonsiirto kantojen välillä (etuajassa) Kulutusseuranta toimii Hallinnointityökalussa paljon toiminnallisuutta (tavoite oli proto) Koko palvelu hyödytön ilman sitä  Kustannuksena raporteista luovuttiin Käyttöopas valmis Testausta niin yksikkö-, integraatio-, kuin järjestelmätasolla. Ongelmana ulkopuolisen resurssin peruuntuminen Java-rajapintatoteutuksessa

9 Projektin eteneminen (3)
I3-vaihe I2-vaiheen rutistuksen johdosta ohjelmoijien resurssit varsin vähäiset  Testaajat tutustuivat vielä järjestelmään ja toteuttivat muutaman asiakkaalle suhteellisen tärkeän bonus-toiminnon. Vertaistestaus suoritettiin molempia osapuolia tyydyttävällä tavalla Hallinnointityökalulle heuristinen arviointi Vertaistestibugien myöhäisen korjaamisen vuoksi loput omat testimme siirrettiin LU-vaiheen alkuun uudelle build:lle. LU-vaihe Build 3.0:n testaus, jossa havaitut virheet korjattiin build 3.1:ksi. Tälle suoritettiin vastaavat testit regressiotestauksena. Asiakkaan koulutus Dokumenttien viimeistely Luovutus-CD:n koostaminen Ongelmana resurssien vähyys  Ratkaisuna taskien allokointi tehtiin jo I3-vaiheen lopussa, jolloin tuntijakauma saatiin kaikille suhteellisen oikeudenmukaiseksi.

10 Jälkilaskelmat - resurssit (1)
Paljon dokumentointia, koska osa sisältää mm. testauksen raportoinnin ja osan suunnittelua ja projektinhallintaa Tapaamiset ovat selkeästi vähentäneet turhaa työtä ja selkiyttäneet eri jäsenten vastuuta kussakin vaiheessa Testaukseen käytetty kurssin ryhmistä eniten aikaa PS: projektinhallinta ja vaatimusmäärittely veivät aikaa I2: ohjelmoijien panostus näkyy I3: testaajien panostus näkyy

11 Jälkilaskelmat - resurssit (2)
PS: ylitys johtui kokemattomuudesta I1: ajankäytön tehostaminen sekä liiallinen varautuminen asiakaspalavereihin ja vaatimusmäärittelyn muutoksiin I2: ylitys panostuspäätöksen seurauksena I3: liiallinen varautuminen palavereihin ja testauksen siirtäminen LU-vaiheeseen LU: onnistui hyvin, koska kokemusta sekä vaihe lyhyt Aiempina vuosina heitto ollut keskimäärin 15%, mutta yli 30% heittojakin löytyi

12 Jälkilaskelmat – laatumittarit (1)
Yleistä projektin testauksesta: Projektin aikana lähdekoodin testausta suoritettu yksikkö-, integraatio- ja järjestelmätestaustasolla Testatut yksiköt järjestelmä, moduuli-integraatio, moduuli, luokka Testitapaukset testitason yksiköille ja tapaukset kytketty järjestelmätestaustasolla käyttövaatimuksiin (käyttötapaukset) Järjestelmätestauksen kohteena buildit, regressiotestaukset korjattujen virheiden jälkeen Tapausten jako järjestelmätestauksessa toiminnallisuuksien mukaisesti testikokoelmiin (test suitet) ja yksikkötestauksessa moduuleittain Staattinen testaus testausprosessin mukaisesti vaatimusmäärittelylle, tekniselle määrittelylle (2x) sekä loppukäyttäjän ja ylläpitäjän manuaaleille

13 Jälkilaskelmat – laatumittarit (2)
PS: vaatimusmäärittely I1: tekninen määrittely I2: loppukäyttäjän käyttö-liittymän heuristinen arviointi I3: käyttäjämanuaalit (3 kpl) LU: tekninen määrittely PS: ei ohjelmoitu I1: moduulitestit I2: eniten toimintoja toteutettu, joten eniten bugejakin I3: vertaistestit ja omat moduulitestit LU: kattavat testit build 3.0 ja 3.1. Testien edetessä bugien määrä ja vakavuus laskivat

14 Jälkilaskelmat – laatumittarit (3)
Testausaktiviteetit projektin aikana: Testaustaso Testauksen kohde Testitapaukset Havaitut virheet* Korjatut virheet* Järjestelmä-testaus IOBASE 1.0 28 7 6 IOBASE 2.0 Vertaistestaus 13 IOBASE 3.0 57 5 3 IOBASE 3.1 58 - Integraatio- testaus Integraatio Building, Database ja Transmission (build ) Yksikkö-testaus Moduulit Building, Database, Transmission (build ) 23 10 Moduulit Building, Database, Transmission (build ) Yhteensä 195 38 32 *ei sis. ad hoc-testausta Staattinen testaus Tekninen määrittely (v0.5 & v2.0) n/a 133 115 Vaatimusmäärittely (v0.12) 66 54 Käyttöoppaat (1.0) 118 94 Yhteensä 317 263

15 Jälkilaskelmat - laadun arviointi
Toiminta-alue Kattavuus Laatu Kommentit Tietokanta 4 J Testattu, kaikki ok. Tiedonsiirto ja kantayhteydet Järjestelmän perustoiminnot (smoke testit) Järjestelmän yleistoiminnot (login, navigointi...) Testattu, kaikki ok. Navigoinnin testeissä joitain pieniä ongelmia (Back-nappula ja manuaalin näkyminen). Käyttäjien hallinta Testattu, bugit saatu korjattua. Kiinteistöjen hallinta Testattu, täyttää vaatimukset hyvin. Joitain rinnakkaisuusongelmia. Raportointi Testattu, kaikki ok Yhteydenpito Järjestelmän toiminta täyttää asiakkaan toiminnalliset ja ei-toiminnalliset vaatimukset Avoimia bugeja 6 kpl 1 major, 3 minor, 2 trivial Järjestelmä täyttää testaukselle asetetut exit-kriteerit (korkean prioriteetin testitapaukset 100% ok, keskitasoiset vähint. 75% ok, matalat 25% ok) Asiakas hyväksynyt I1-LU –vaiheiden iteraatiot vaihekatselmointien yhteydessä Selitykset Kattavuus: 2 = kaikki toiminnot tarkastettu 3 = testattu osin 4 = testattu Laatu: J = hyvä K = ei varmuutta L = huono

16 Jälkilaskelmat – ohjelmiston koko koodiriveinä
Kuvasta puuttuvat JSP-sivujen koodirivit I2-vaiheessa toteutettiin eniten I3-vaiheessa tehtiin muutama bonus-toiminto

17 Tulokset Ryhmän itselle asettamista tavoitteista kurssille toteutui täysin 4/5 ja tavoite ”Kurssin suorittaminen annetuissa resurssirajoissa (210h/jäsen)” osittain. Asiakkaalla oli 10 tavoitetta, joista täysin täyttyivät sovitut toiminnot on toteutettu jatkokehitys tuotteelle mahdollista järjestelmän arkkitehtuuri sopii olemassa olevaan järjestelmään toteutettu järjestelmä on käytettävyydeltään hyvä toteutettu järjestelmä on luotettava toteutus on hyvin dokumentoitu onnistunut yhteistyö asiakkaan ja projektiryhmän välillä ja osittain täyttyivät toteutettu järjestelmä on riittävän suorituskykyinen toteutettava järjestelmä on skaalautuva projektiryhmän käyttämät resurssit eivät ylitä sovittua määrää Osittain täyttyneistä kaksi ensimmäistä eivät toteutuneet täysin, koska asiakas halusi itse tehdä tarvittavat rasitustestit, kun järjestelmä viedään tuotantoon. (projektissa toteutettiin prototyyppi, eikä järjestelmää pitänytkään testata suorituskyky jne. alueiden osalta).  Palvelua tosin jo käytetty reaaliaikaisesti Internet:in yli demoissa

18 Tulokset - jatkokehitysnäkymät
Jatkokehitys jää asiakkaan vastuulle alkaen Kehitystyö tehty asiakkaan tiloissa Asiakas päässyt seuraamaan tuotteen kehittämistä päivittäin Asiakasta koulutettu (Enterprise Manager + ohjelmakooditason koulutus) Tuote tehty sovittujen standardien mukaan  Erittäin hyvät edellytykset toteuttaa jatkokehitystä Tulevaisuuden haasteita: Raportit: kannan osalta jo tuettu Eräajot datan keräämiseen: asiakasta ohjeistettu alustavasti Korjaamattomat bugit (6 kpl) Vaatimuksista toteutettu: 11/11 pakollisista 9/14 suositeltavista (lähinnä raportit puuttuivat) 5/11 lisätoiminnoista Loput vaatimukset jäävät asiakkaan toteutettaviksi

19 Työmenetelmät ja työkalut (1)
Käytetyt menetelmät: arkkitehtuurisuunnittelu (raskas projektiimme) dokumentointikäytännöt (yhdenmukaisuus, laadukkuus) heuristinen arviointi (käytettävyys) katselmointikäytännöt (yhdenmukaisuus, laadukkuus) konfiguraationhallinta (raskas projektiimme) tapaamiskäytännöt (ryhtiä, projektinhallintaa) vaatimusmäärittely (suuntaviivat, sopimus toteutuksesta) riskienhallinta (raskas projektiimme Riskit:llä) ohjelmointikäytännöt (JavaDoc ja SQLDoc)(yhtenäisyys, jatkokehitettävyys) pakolliset: ajanseuranta, versionhallinta (välttämättömiä) Henkilökohtaisten menetelmien kokemukset (vaiheittain) on koottu kukin omaan dokumenttiinsa projektin kotisivulla Muiden menetelmien hienojakoisempi arviointi on loppuraportissa Tulevaisuudessa kaikki käyttökelpoisia: käyttö harkittava projektikohtaisesti

20 Työmenetelmät ja työkalut (2)
Käytetyt työkalut: Trapoli (projektin seuranta) (helppokäyttöinen) CVS (välttämätöntä versionhallintaa) Bugzilla (bugiraportointi) (heikko käytettävyys) Poseidon (UML-kaaviot) (nopea käyttää) SmartDraw (kuvat ja diagrammit) (monipuolinen) UltraEdit (tekstieditori) (paljon lisätoimintoja) JBuilder (sovelluskehitin) (nopea koodata) MS SQL Server (tehokas ja ylläpidettävä) Apache TomCat Server (”good enough”) Työkalujen hienojakoisempi arviointi on loppuraportissa Oman projektimme kannalta kaikki työkalut olivat välttämättömiä Tulevaisuudessa käyttäisimme kaikkia muita paitsi Bugzillaa, koska sen käyttöliittymä on varsin sekava

21 Oppiminen Mitä opittiin? Mitä olisi voitu tehdä eri tavalla?
Toimimaan yhteistyössä Ohjelmistoprosessin kulku alusta loppuun Uusia menetelmiä ja työkaluja Ajankäytön hallintaa ja omien resurssien tarkempaa arviointia Asiakkaan tärkeimpien vaatimusten tunnistamista Use Case:ien avulla Asiakkaan kanssa toimimista Dokumentointia Kattavan testauksen suunnittelua ja suorittamista Tuotteen arviointia Mitä olisi voitu tehdä eri tavalla? PS-vaihe olisi pitänyt suunnitella heti kurssin alussa Palaverit olisi pitänyt tehostaa heti jo PS-vaiheessa I1-vaiheeseen olisi voinut ehkä lisätä tehtäviä ja käyttää tunteja jo projektin aiemmalla puoliskolla

22 Kurssipalaute Yleisesti ottaen ryhmä on tyytyväinen kurssijärjestelyihin Tarkempi erittely loppuraportissa Mitä asioita voitaisiin parantaa kurssissa? Olisimme toivoneet enemmän kannanottoa sekä mahdollisesti jopa kyseenalaistamista kurssin puolesta teknisiin ratkaisuihin Kurssin kotisivulta on hiukan hankalaa löytää tietoa Oma menetelmä vei paljon aikaa pois kurssista Voisi ehkä muodostaa 2-3 hengen ryhmäkäytäntöjä Lisäksi projektin etenemisestä saatavan palautteen määrää voisi lisätä esim. ryhmien välisellä opponoinnilla, johon käytettäisiin muutama tunti jokaisessa vaiheessa.

23 Kysymyksiä?

24 PPT kiittää!