T Projektikatselmus Ampel 1. Toteutusvaihe

2 T Project Review Agenda  Projektin edistyminen (10-15min)  Tavoitteisiin pääsy  Projektin metriikkaa  Muutokset suunnitelmiin  Käytäntöjen & työkalujen käytöstä (5 min)  Tuotosten esittely (15-20min)  Paperiprototyyppi  Tekninen määrittely  Demo  Seuraavan vaiheen suunnitelma (5 min)  Toteutus II -vaihe

3 T Project Review Suunniteltujen tavoitteiden tilanne  Ampel-arkkitehtuurin (API & Core) ensimmäinen versio (ok!)  Liikennepelin ensimmäinen versio (ok!)  Tekninen määrittely (ok!)  Testaussuunnitelma (ok!)  Toteutetaan testaus (ok!)  Dokumenttien tarkentaminen (ok!)  Alustavat vaatimusmäärittelyt ViaSys Oy:n kanssa. (ok!)  Liikennepelin UI-grafiikkan ja mannerheimintie-liikennemallin lopullisen muodon selvittäminen prototyyppaamalla. (ok, mutta päätöstä ei tehty)  Kehitysympäristö (ok!)  Sopimus tekijänoikeuksista (ok!)

4 T Project Review Tuotoksien tilanne  Päivitetty projektisuunnitelma  Uusia tavoitteita  Päivitetty vaatimusmäärittely  Uusia vaatimuksia (liikennelabralta)  Huomasimme, että liikennelaboratorion vaatimusmäärittely uupuu kokonaan  Tekninen määrittely  Sanasto, skenaarioita, rajapintamääritelmät, analyysi- ja suunnittelutason mallit  Ampel Core, Ampel API ja liikennepeli  HUTSIM-rajapinta ja HUTSIM-muutokset  Testausraportti

5 T Project Review Tehtävien toteutuminen (1/2)  Huomautettavaa  Tuntiraportointia ja kategorioita päivitetty rankalla kädellä  Käytetty yhteistuntimäärä on 770h (110% suunnitellusta).  Ylitykset: HUTSIM-rajapinnan määrittäminen ja toteutus: 20h (350% suunnitellusta), Ampel API & Core: 45h (150% suunnitellusta)

6 T Project Review Tehtävien toteutuminen (2/2)

7 T Project Review Henkilötuntien käyttö  Viimeisin ajankäyttösuunnitelma tehty  121% vaiheen tunneista käytetty  54% projektin tunneista käytetty  Ylityksiä

8 T Project Review Henkilötuntien käyttö – kaikki iteraatiot  (Tuntien käyttö per henkilö koko projektin ajalta)

9 T Project Review Laatumetriikat  Huomioita  Tässä vaiheessa tärkeimmät testausmenetelmät olivat staattiset koodikatselmukset sekä yksikkötestit. Yllä vasemmalla oleva taulukko kuvaa niiden kattavuutta. Ylhäällä oikealla oleva taulukko viittaa koodikatselmuksissa löydettyihin asioihin. Varsinaista systemaattista järjestelmätestausta ei tehty järjestelmän matalan integrointiasteen takia.  Tässä projektivaiheessa ei ole esitetty reported/closed –statistiikkaa virheille, koska testaus tehtiin vasta vaiheen lopussa ja virheiden systemaattinen korjaaminen ja niiden tilan seuraaminen on ajankohtaista vasta seuraavassa iteraatiossa. Yksikkötestien luonteen mukaisesti niillä löytyvät virheet korjattiin osana normaalia koodausprosessia. Testien kattavuus Bugimetriikat

10 T Project Review Laatuarvio  Huomioita  Tässä vaiheessa ei asetettu mitään yksiselitteisiä testien läpäisyprosentteihin tai vastaaviin liittyviä laatuvaatimuksia.  Toiminnallisena vaatimuksena oli, että tärkeimmät viestit kulkevat Ampel Coren läpi HUTSIM:ilta liikennepelille ja että liikennepeli osaa visualisoida karkeasti objektien liikettä  Laatuvaatimuksena oli, että toiminnallisten vaatimusten täyttymisen pystyy toteamaan järjestelmää ajamalla, siis se että järjestelmä ei kaadu kesken perustoiminnallisuuden testausta.  Sekä toiminnalliset että laatuvaatimukset on tämän vaiheen osalta täytetty. Vastaa vaiheen tavoitteita  1Ampel Core and Api Vastaa vaiheen tavoitteita  1Liikennepeli CommentsQualityCoverageFunctional area Legend Coverage: 0 = nothing 1 = we looked at it 2 = we checked all functions 3 = it’s tested Quality:  = quality is good  = not sure  = quality is bad

11 T Project Review Ohjelmiston kokometriikkaa

12 T Project Review Riskit  Tärkeimmät riskit on koostettu poimimalla riskianalyysiin käytetystä ns. pareto-taulukosta riskit, jotka ovat lähimpänä vasempaa yläkulmaa (suurin todennäköisyys*toteutuneen riskin vaikutus).  Uusia riskejä  Skenaario 11: Ampel API ei tarpeeksi uudelleenkäytettävä (7.11.)  Skenaario 12: Ongelmia ei ehditä ratkaisemaan ajoissa (13.11.)  HUTSIM liian buginen näyttelykäyttöön, eikä pysy pystyssä (7.11.)  Vanhentuneita  Skenaario 8: Ohjelmointiympäristöä ei saada pystytettyä ajoissa

13 T Project Review Käytännöt ja Työkalut  Arkkitehtuurisuunnittelu  Together, Eclipse ja muiden työkalujen toiminta  Testauslähtoinen ohjelmistokehitys  Projektin seuranta ja hallinta

14 T Project Review Vaiheen tuotokset  Paperiprototyyppi  Tekninen määrittely  Demo  Ampel Core  Ampel API  Traffic Control Game  Muutokset HUTSIMiin

15 T Project Review Paperiprototyyppi  Taustat & Tavoitteet  Tekeminen  Esittelyt  Lopputulokset

16 T Project Review Vaatimusten toteutuminen  Toiminnalliset vaatimukset (Heureka)  Kriittiset: 6/7 toteutettu  Korkeat: 2/6 toteutettu  Matalat: 0/4 toteutettu  Toiminnalliset vaatimukset (Viasys)  0/8 toteutettu  Ei-toiminnalliset vaatimukset  4/4 toteutettu, joskin toteutumisaste vaikea määritellä

17 T Project Review Tekninen määrittely  Toteutuksen tässä vaiheessa määritelty  Järjestelmäarkkitehtuuri  Pakkaukset  Komponentit (moduulit)  Järjestelmän rakenne  APIn luokkarakenne  Varsinaisen toteutuksen luokkarakenne  Liikennepelin luokkarakenne  Ampelin ja HUTSIMin välinen rajapinta  Tekstipohjainen TCP/IP-yhteys  Teknisen määrittelyn pohjana Heurekan ja Liikennelaboratorion vaatimukset  ViaSysin tämänhetkiset vaatimukset analysoitu siltä tasolta, että järjestelmäarkkitehtuuri vastaa niihin.  Ampel pähkinänkuoressa:  Uudelleenkäytettävä arkkitehtuuri toteutetaan ’kirjastona’, ei itsenäisenä prosessina  Varsinainen toteutus kätketään APIn (Sovellusrajapinta) alle  Ei hankalia rajapintoja, Ampelin ja sitä käyttävien sovellusten välinen sovitustyö minimoitu  APIn päälle rakennetaan varsinaiset sovellukset  Liikennepeli  ViaSys –visualisaatio

18 T Project Review Tekninen määrittely / Pakkaukset

19 T Project Review Tekninen määrittely / Luokkakaaviot

20 T Project Review Demo

21 T Project Review Toteutusvaihe 2: Tavoitteet  Tavoitteet  1. Heurekalle liikennepelin lopullinen versio  2. Peliympäristön ja grafiikan sekä UI:n lukkoonlyönti  3. Peligrafiikan ja laitteiden tilaus Heurekalta  4. Käytetyn simulaattorimallin (Mannerheimintien) lopullinen ulkomuoto  5. HUTSIM:in muutosten toteuttaminen  6. Ampel API:n ja Core:n seuraava versio  7. Liikennepelin asennus- ja huolto-ohje  8. Ampel API:n ja Core:n käyttöohje  9. Aloitetaan 3d-visualisoinnin määrittelyä ja suunnittelua (ViaSys).  10. Seuraava versio HUTSIM- rajapinnasta

22 T Project Review Toteutusvaihe 2: Tuotokset

23 T Project Review Toteutusvaihe 2: Tuntien jakautuminen