Projektisuunnitelma - StatbeatMOBILE
|
|
- Niina Tikkanen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 Projektisuunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus Verkkoperä Alustava luonnos / rakenne Westin Tekstin kirjoittamista ja rakenteen päivitystä Westin Lukujen 2, 3.2, 5 ja 6 kirjoittamista Verkkoperä Luvun 1 ja 5 kirjoittamista Pöyry Luvut ja Westin Hienosäätöä Verkkoperä Luvun 1 ja 3 kirjoittamista Westin Luvun 5.2 kirjoittamista (QA-suunnitelma) Westin Lukujen 5.2 ja 6.1 päivittämistä. 1. Johdanto 2. Sidosryhmät ja projektin henkilöstö 3. Tavoitteet 3.1 Projektin tavoitteet 3.2 Henkilökohtaiset oppimistavoitteet 4. Resurssit 4.1 Henkilöresurssit 4.2 Muut resurssit 5. Työskentelytavat ja käytännöt 5.1 Käytännöt 5.2 Laadunvarmistussuunnitelma 6. Projektin vaiheet 6.1 Aikataulu 6.2 Sprinttikohtaiset suunnitelmat 7. Riskianalyysi 1
2 1. Johdanto Tämä projekti on Aalto-yliopiston T Software development project -kurssin pakollinen työ. Projektisuunnitelma on kirjoitettu kurssin henkilökunnalle. Statbeat on selainpohjainen joukkueurheilupalvelu, jossa voi keskitetysti hallita joukkuetta sekä kartuttaa tilastoja. Ensi vuoden aikana Statbeatin käyttäjät tulevat odotusten mukaan lisääntymään turnauspalvelun myötä, jonka takia palvelun kehitys on ajankohtaista. Projektin tavoitteena on parantaa yleisesti käyttäjien mobiilikokemusta applikaatiolla sekä tehdä nykyisistä ominaisuuksista helppokäyttöisempiä. Lisäksi tavoitteena on vertailla natiivin applikaation, hybridin applikaation ja selaimen nopeuseroja. Projektiryhmästä neljä (4) on kehittänyt Statbeatia jo aikaisemmin. Projektin asiakkaana on Fast Monkeys. 2. Sidosryhmät ja projektin henkilöstö Projektiryhmän kokoonpano on taulukossa alla. Henkilöstön yhteystiedot, esimerkiksi sähköpostiosoitteet ja puhelinnumerot, eivät ole tässä julkisessa dokumentissa vaan löytyvät ryhmän Google Drive -tallennuspaikasta, johon asiakkaalla, mentorilla ja kurssin vastuuhenkilöllä on käyttöoikeudet. Nimi Rooli Kurssi Verkkoperä, Sami PP cr Westin, Arne QA cr Pöyry, Pekka AR cr Anttilainen, Eero Keh cr Belt, Teemu Keh cr Hiltunen, Oskari Keh cr Leppäkorpi, Tuomas Keh cr Raivio, Lauri Keh cr Väyrynen, Joni Keh cr Asiakkaana on Eero Vehmanen FastMonkeysilta. Mentorina toimii Petteri Räty. 2
3 3. Tavoitteet 3.1 Projektin tavoitteet Projektin ensimmäisenä tavoitteena on Statbeat-käyttäjien mobiilikokemuksen parantaminen. Tällä hetkellä Statbeatilla on responsiivinen sivusto, jota halutaan viedä askel eteenpäin hybridi -applikaation toteuttamisella. Hybridi applikaatio tarkoittaa sitä, että natiivin applikaation sisään rakennetaan HTML -pohjaisesti sisältöä. Toisena tavoitteena on, ettei sidota palvelua liikaa natiiviteknologioihin. Asiakkaalle on tärkeää, että otamme huomioon Statbeatin jatkokehityksen. Hybridi -applikaatioon pystyy tekemään natiivisti paljon ominaisuuksia haluttaessa. Tärkein natiivi ominaisuus projektissa on notifikaatiot. Kolmantena tavoitteena on tuottaa laadukasta jälkeä, jotta jatkokehitys onnistuu helposti HTML5 -ja JavaScript/CoffeeScript -painotteisesti. Pyrimme tarkastamaan koodin laadun aina kun sitä kirjoitetaan lisää. 3.2 Henkilökohtaiset oppimistavoitteet Henkilö Sami Arne Oppimistavoite Löytää toimivia toimintatapoja projektin johtamiseen ja saada asioita tapahtumaan. Oppia virheistä ja huomata mikä toimii ja mikä ei. Luoda miellyttävä ryhmähenki ja saada kaikki puhaltamaan yhteen hiileen yhteisen tavoitteen eteen. Työskentelen suuressa IT-talossa, jossa talon prosessien ja tehtävien projektien luonteiden takia ei aina voida tehdä asioita erityisen ketterästi. Tässä projektissa haluan nähdä ja kokea miten hyvin ketterä, hieman Kanban-tyylinen eteneminen onnistuu, ja mitä hyötyjä ja haittapuolia toimintatavassa on. Tavoitteeni on auttaa projektipäällikköä projektin pyörittämisessä, tarjota kehittäjille parhaat mahdolliset edellytykset tehokkaaseen työskentelyyn ja varmistaa korkealaatuinen lopputuote. Pekka Tavoitteena oppia tekemään ja perustelemaan projektin teknisistä asioista tehtäviä päätöksiä. Lisäksi haluan saada kokemusta hybridi applikaatioiden kehityksestä Android ja mahdollisesti myös ios alustalla. Oppia löytämään 3
4 teknisesti mahdollisimman yksinkertaisia ratkaisuja, jotka täyttävät mahdollisimman hyvin asiakkaan nykyiset ja tulevat vaatimukset. Eero Teemu Oskari Tuomas Lauri Joni Saada hieman lisää kokemusta mobiilikehityksestä, suunnittelusta ja käytettävyyden testaamisesta. Tutustua ketterään ohjelmistokehitykseen ja saada käytännön kokemusta työskentelystä kaupallisen ohjelmistoprojektin parissa. Oppia lisää responsiivisten nettisivujen kehityksestä, Android-kehityksestä sekä hybridiapplikaatioista. Oppia ohjelmistoprojektin käytännön toiminnasta sekä saada kokemusta mobiili- ja Android kehityksestä. Oppia JavaScript koodin järkevä jäsentäminen ja testaaminen sekä projektien kehittäminen Angular.js:llä. Test driven development menetelmän hyödyntäminen kehityksessä. Oppia toimimaan ohjelmistoprojektin jäsenenä ja kehittää osaamistani HTML, Javascript ja CSS tekniikoiden kanssa. 4. Resurssit 4.1 Henkilöresurssit Projektiryhmän budjetoidut kokonaistyömäärät, viikkokohtaiset työmääräarviot ja toteutuneet työtunnit löytyvät erillisestä tuntikirjanpitodokumentista. 4.2 Muut resurssit Projektissa käytetään omia tietokoneita sekä Aalto-yliopiston tiloissa olevia julkisia tietokoneita. Erillisiä kehitys- tai testilaitteita ei ole. Ensimmäisessä iteraatiossa ryhmä työskentelee yhdessä Maarintalon tiloissa, myöhemmin mahdollisesti asiakkaan tiloissa. 5. Työskentelytavat ja käytännöt 5.1 Käytännöt Iteratiivinen kehittäminen PALAVERI KERRAN VIIKOSSA Perjantaisin ryhmällä on devauspäivä. Tarkoituksena on jauhaa yhdessä kokonainen päivä 4
5 koodia ja saada tehtäviä valmiiksi. Jossain vaiheessa päivää pidämme palaverin, jossa katsotaan ryhmän status. Selvitetään mitä on saatu aikaiseksi, täytetään tehtävien toteutuneita tunteja ja tuntiarvioita, mietitään uusia tehtäviä ja sovitaan mitä tehdään. TEHTÄVIEN ASETTAMINEN Tehtävät sovitaan yhdessä devauspäivän palavereissa projektipäällikön tai jonkun muun vetäjän aloitteesta. Tehtävät asetetaan sprinttien alkaessa. Kun tehtävä on valmis, se siirretään sprintin aikana tehtyjen tehtävien listaan. Jos sprintin ajaksi asetetut tehtävät saadaan valmiiksi, sprintille voidaan lisätä uusia tehtäviä. Käytämme Trelloa tehtävien hallinnoimiseen kanban -tyylisesti. Esimerkiksi tällä hetkellä Trellossa ovat nämä vaiheet: Backlog, Sprint 0 Done, Sprint 1, Sprint 1 Done. Backlogissa on aiemmissa palavereissa sovittuja tehtäväehdotuksia ja asiakkaan tehtäväehdotuksia, joiden tekemisestä ei ole vielä päätetty. Haluamme tehdä koko ajan tärkeintä tehtävää emmekä voi mitenkään tietää sitä etukäteen. Esimerkissä esitetty Sprint 0 Done jätetään kanbaniin siksi, että kaikki projektin jäsenet tietävät myöhemminkin, mitä on tehty. TEHTÄVÄN JAKAMINEN OSIIN Tehtävät koostuvat eri tyyppisistä osista. Eri henkilöt kuuluvat usein samoihin tehtäviin, joissa he toteuttavat oman osansa. Tehtävän osat voivat koostua mm. ohjelmoinnista, suunnittelusta ja testauksesta. Mitään ei tämän tarkemmin aikatauluteta, vaan oletus on että tehtävät tehdään niin nopeasti ja hyvin kuin osataan, jonka jälkeen mennään eteenpäin. TEHTÄVÄN ELINKAARI Tehtävä ensin määritellään yhdessä, jonka jälkeen se tehdään, testataan, demotaan ja sen jälkeen mietitään pitääkö sitä parantaa. Jos tehtävää pitää parantaa, se laitetaan kanbanin backlogiin josta se saatetaan ketterästi vaihtaa jonkun uuden sprintin tehtävän kanssa. Valmiit tehtävät voidaan näyttää asiakkaalle tai kenelle tahansa helposti tarjoamalla aina linkki uusimman aplikaation lataamiseen. ( Kaikki sprintille asetetut tehtävät eivät välttämättä toteudu sprintin aikana, eikä ole tarkoituskaan. Ne voidaan siirtää seuraavalle sprintille. Yritämme kuitenkin arvioida mahdollisimman tarkasti kuinka paljon tehtäviä voidaan sprintin aikana tehdä ja oppia lisää arvioimisesta. TESTI EDELLÄ Tehtävän alussa luodaan testejä valmiille toimivalle funktiolle. Testit eivät aluksi tietenkään onnistu, koska koodia ei ole vielä kirjoitettu. Kun tehtävä on valmis, testit ajetaan läpi ja saatetaan tehdä lisää testejä tarvittaessa. Luomme myös testiympäristön 5
6 jonka tarkoituksena on automatisoida testaus. Testiympäristö koostuu merkittävästä määrästä yksikkötestejä ja END-to-END -testejä Sprinttien suunnittelu SPRINTIN HUUMAA Jaamme projektin sprintteihin kurssin takia. Yksi sprintti voi kestää parista viikosta kuukauteen riippuen joululomista ja muista hätäpäivistä. Yhden sprintin aikana voidaan tehdä tässä projektissa muutamia tehtäviä / henkilö. SPRINTTEJÄ EI SUUNNITELLA ETUKÄTEEN Tarkoituksena on tehdä jatkuvasti projektin tärkeintä tehtävää, jonka takia emme voi suunnitella sprinttejä, koska jatkamme aina vain tärkeimmän tehtävän tekemisellä. Tällä tavalla teemme suunnittelussa vähiten virheitä ja pystymme muuttamaan päätöksiä tarvittaessa nopeasti. TEHTÄVIEN ARVIOINTI SPRINTEITTÄIN Vaikka emme suunnittele etukäteen sprinttejä, pyrimme arvioimaan kurssin takia mahdollisimman tarkasti mihin pystymme sprintin aikana ja päätämme tehtävät sprintin alkaessa. Emme siis suunnittele sprinttejä etukäteen, mutta suunnittelemme tehtävämme silloin kun sprintti alkaa. PARIOHJELMOINTI VAIKEUTTAA ARVIOINTIA Projektiryhmässämme on eritasoisia henkilöitä, jonka takia päätimme käyttää pariohjelmointia. Pariohjelmoinnin tarkoitus tässä projektissa on, että devauspäivinä parista kokemattomampi oppii asioita nopeasti. Ryhmämme muodosti kaksi paria: Lauri ja Joni sekä Eero ja Tuomas. Pariohjelmointi vaikuttaa tehtävien tuntiarvioihin Dokumentointi Projektissa käytetään Google Drivea dokumenttien luomiseen ja tallentamiseen. Koko ryhmällä, asiakkaan edustajalla ja mentorilla on käyttöoikeudet tallennuspaikkaan Riskienhallinta Projektin riskienhallintaprosessi on seuraavanlainen: 1. Riski tunnistetaan ja sen hetkinen tilanne kartoitetaan 2. Riski analysoidaan yrittämällä selvittää sen vaikutukset ja erilaiset korjaavat toimenpiteet 3. Riskin realisoituessa suoritetaan korjaavat toimenpiteet 4. Korjaavien toimenpiteiden vaikutus tarkistetaan ja riskin tilanne kartoitetaan uudestaan 6
7 Riskienhallintaa suoritetaan koko projektin elinkaaren ajan. Riskiloki löytyy erillisestä dokumentista Työajan seuranta Kokonaistyöajan seurantaa suoritetaan viikkotasolla. Projektiryhmä merkitsee tunnit vähintään kerran viikossa Google Drivessa sijaitsevaan tuntikirjanpitotaulukkoon, johon on merkitty henkilökohtaiset työmäärätavoitteet (kurssin pistemäärän mukaisesti, 1 opintopiste vastaa 27 tuntia) sekä iteraatio- ja viikkokohtaiset aikatauluarviot. Ominaisuus- tai tehtäväkohtaiset tunnit merkitään Trelloon (kts. luku Viestintä). Ryhmä käyttää Scrum for Trello -selainlisäosaa, joka hyödyntää Trellon tietyllä syntaksilla merkittyjä työmääräarvioita ja kokonaistuntimääriä Viestintä Ryhmä työskentelee kerran viikossa (pääsääntöisesti perjantaisin) yhdessä samassa tilassa, jolloin viestintä onnistuu kasvokkain. Kun kaikki osallistujat ovat paikalla, pidetään lyhyt Scrum-tyyppinen palaveri jossa kukin kertoo mitä on tehnyt sitten viime palaverin, mitä ongelmia on ollut ja mitä tulee tekemään seuraavaksi. Yhteisten työskentelypäivien ohella pääasiallisena viestintämenetelmänä käytetään Flowdockia, jonka käyttöoikeudet on myönnetty projektiryhmälle, asiakkaan edustajalle ja mentorille. Viestintää muissa järjestelmissä pyritään välttämään, jotta kaikki oleellinen viestintätieto löytyisi yhdestä järjestelmästä. Projektinhallintajärjestelmänä toimii Trello, jonne kirjataan ominaisuudet ja tehtävät sekä niiden työmääräarviot ja toteutuneet työtunnit. Trellosta ryhmän jäsenet näkevät mitä muut tekevät ja saavat kokonaiskuvan projektin etenemisestä. Trello on integroitu Flowdockiin, jolloin sinne tulee merkintä Trellossa tapahtuneista muutoksista (esim. ominaisuus valmistuu). Ryhmän Trello-alue ei ole julkisessa käytössä, mutta asiakkaalla, mentorilla ja kurssivastuuhenkilöllä on käyttöoikeudet. Ryhmällä on oma Google-kalenteri, johon merkitään tapaamiset, deadlinet ja muut projektiin liittyvät tapahtumat. Kalenterimerkinnöistä ja -päivityksistä tulee automaattisesti tieto Flowdockiin. Projektin GitHub-repositorio on myös integroitu Flowdockiin, jolloin versiohallintamuutoksista ja GitHub-issueista tulee automaattinen ilmoitus. Ryhmällä on kotisivu dokumenttien toimittamista ja tärkeiden resurssien ja linkkien jakamista varten. 7
8 5.1.7 Bugien seuranta Löydetyt bugit kirjataan GitHubiin issueiksi. Laajemmista ongelmista tai isommista virheistä tehdään Trelloon tehtävä, joka aikataulutetaan tilanteesta riippuen joko kyseiseen tai tulevaan sprintiin (alhaisen prioriteetin tehtävän tapauksessa se saatetaan asettaa backlogiin odottamaan tarkempaa aikataulutusta) Versionhallinta Projektissa käytetään asiakkaan myöntämiä GitHub-versiohallintarepositoriota. Sovelluksen taustalla pyörivälle verkkosivustolle ja jokaiselle mobiilisovellukselle on omat repositoriot. Kaikki kunkin sovelluksen käyttämä sisältö on sen omassa repositoriossa. Jokaisen commitin tulisi sisältää vain yhteen asiaan liittyviä muutoksia, ja sillä tulisi olla sen sisältöä kuvaava selkeä kommentti. Verkkosivustossa pyritään siihen, että kaikki uusi koodi lisätään omaan branchiin, josta joku toinen ohjelmoija käy hyväksymässä tämän muutokset, ennen kuin ne lisätään varsinaiseen tuotantoversioon. Verkkosivuston repositorio on linkitetty testauspalveluun, joka ajaa jokaiselle muutossarjalle kaikki testit. Koska verkkosivusto päivittyy jatkuvasti, ei sen repositoriossa käytetä tageja. Mobiilipuolen ohjelmissa jokainen sovelluskauppaan lähetetty versio merkitään sen versionumeroa vastaavalla tagilla. Mobiilipuolella julkaisujen välillä pidetään kirjaa tehdyistä muutoksista, jotta nämä tiedot voidaan näyttää ohjelman käyttäjille ohjelmakaupassa. Kaikki suuremmat prototyyppitestaukset pyritään tekemään omiin brancheihin, jotta niiden välillä voidaan liikkua helposti Prosessien kehittäminen Jokaisen iteraation viimeisessä tapaamisessa ryhmällä on retrospektiivi, jossa käydään läpi iteraation tapahtumat. Ryhmä yrittää selvittää mikä onnistui, mikä olisi voinut mennä paremmin ja miten tilannetta voidaan parantaa seuraavassa iteraatiossa. PI-vaiheen retrospektiivissä todettiin, että vaikka projekti oli lähtenyt vauhdilla käyntiin ja tuloksia saatiin nopeasti, olisi projektin kokonaiskuvan ja vision muodostamiseen voinut käyttää enemmän aikaa ryhmänä yhteisesti. Päätettiin, että seuraavan iteraation alussa pidetään ylimääräinen suunnittelusessio, jossa asiaan paneudutaan tarkemmin Vaatimusmäärittely Ryhmä suorittaa vaatimusmäärittelyä asiakkaan kanssa käytyjen keskustelujen perusteella. Vaatimukset kirjataan korkealla tasolla Trellon backlog-listaan ja pilkotaan pienempiin 8
9 osiin checklistin avulla. Ryhmä määrittelee vaatimuksille työmääräarviot ja priorisoi ne asiakkaan toiveiden mukaan Arkkitehtuurisuunnittelu Rakennettavan projektin arkkitehtuurista päätettiin asiakkaan kanssa tehtyjen kattavien keskustelujen aikana asiakkaan tavoitteiden perusteella. Kyseisiä keskusteluja järjestettiin muutamia kertoja, ja niiden välillä suoritettiin eri vaihtoehtojen teknistä arviointia. Kyseisissä keskusteluissa kaikki suurimmat tekniset ratkaisut lyötiin lukkoon. Ketterän kehitystekniikan ja joustavien tavoitteiden takia koko projektin kaikkia arkkitehtuurisia päätöksiä ei yritetä tehdä heti projektin alkuvaiheessa, vaan ilmenevät ongelmat ratkaistaan kun ne tulevat ajankohtaisiksi. 5.2 Laadunvarmistussuunnitelma Laatutavoitteet ID Nimi ja kuvaus Toteutus ja verifiointi Prioriteetti LT 1 Helppokäyttöisyys Sovelluksen on oltava helppokäyttöinen ja helposti opittava. Arviointi ryhmässä sisäisesti, asiakkaan kanssa ja vertaistestausryhmän kanssa. Korkea LT 2 Nopeus ja sulavuus Sovelluksen on toimittava sulavasti, ilman selkeästi häiritsevää hidastelua, nykyaikaisilla puhelimilla. Arviointi ryhmässä sisäisesti, asiakkaan kanssa ja vertaistestausryhmän kanssa. Testausta eri puhelinmalleilla ja -käyttöjärjestelmillä. Korkea LT 3 Ylläpidettävyys Sovelluksen on oltava helposti ylläpidettävä ja jatkokehitettävä asiakkaan resursseilla. Koodin arviointi ja katselmointi ryhmän sisällä. Natiivikoodin on oltava mahdollisimman kevyttä pitäen suurimman osan sovelluslogiikasta frontend-puolella. Korkea LT 4 Koodin laatu ja ymmärrettävyys Koodi on laadukasta, yhtenevää sekä helposti ymmärrettävää ja muokattavaa. Noudatetaan ohjelmointikonventioita ja -standardeja. Koodia vertaiskatselmoidaan (Git pull Kohtalainen 9
10 request) ja analysoidaan ryhmän sisällä Laatukäytännöt Käytäntö Kuvaus Vaikuttaa Milloin Yksikkötestaus Koodi yksikkötestataan ja testejä ajetaan jatkuvasti (myös CI:n avulla, kts. jatkuva integraatio). TDD (testausvetoinen kehitys) Mahdollisuuksien mukaan hyödynnetään TDD:tä, jossa (yksikkö-)testi kirjoitetaan ennen sitä toteuttavaa funktiota/toimintoa. Kaikkea koodia ei ole järkevä tai edes mahdollista testata, mutta mikäli koodi on testattavaa, kirjoitetaan testi ensin. Pariohjelmointi Ominaisuuksia toteutetaan pariohjelmoinnin avulla, jossa kaksi henkilöä kirjoittaa koodia ja selvittää ongelmia yhdessä. Koodin vertaiskatselmointi Koodi vertaiskatselmoidaan Githubin pull requestien avulla. Kts. luku Koodin staattinen analysointi Ohjelmakoodia analysoidaan erilaisilla työkaluilla (esim. jshint), jotka pyrkivät löytämään syntaksi- ja logiikkavirheitä. Asiakasviestintä Asiakkaan kanssa viestitään jatkuvasti. LT1, LT2, LT3 Vertaistestaus Vertaistestausryhmä testaa sovellusta toisen iteraation aikana ja raportoi löydöksensä ja kommenttinsa kirjallisesti. LT1, LT2 I2 Tutkiva testaus (exploratory testing) Ryhmän jäsenet suorittavat tutkivaa testausta kehitystyön ohessa. Lisäksi ryhmä järjestää I1:n ja I2:n aikana keskitetyt ET-istunnot. LT1, LT2 I1, I2 / jatkuvasti Koodin refaktorointi Koodia ylläpidetään, modularisoidaan ja parannellaan jatkuvasti tarpeen mukaan. 10
11 Bugien seuranta Bugien seurannassa ja raportoinnissa käytetään Githubin issueita. Kts. luku Jatkuva integrointi Versiohallintarepositorio kytketään FastMonkeysin Travis CI -instanssiin, joka ajaa testit jokaisen versiohallintamuutoksen yhteydessä. Lisätietoja luvussa I1:stä lähtien jatkuvasti Testitapauspohjaine n testaus I1:n ja I2:n lopussa ryhmä suorittaa testausta ennalta määriteltyjen testitapausten pohjalta. Kts. testitapausdokumentti. LT1, LT2 I1:n ja I2:n lopussa Koodikonventiot ja tyyliohjeet Frontendin osalta noudatetaan AngularJS:n ja Javascriptin tyyliohjeita. Androidissa seurataan Oraclen Java Code Conventionsia. ios-sovelluksen osalta pyritään mahdollisimman pitkälle noudattamaan Applen ohjeita. 6. Projektin vaiheet 6.1 Aikataulu 6.2 Sprinttikohtaiset suunnitelmat Projektin sprinttikohtaiset suunnitelmat löytyvät ryhmän Trello-alueelta (ei julkinen). 11
12 7. Riskianalyysi Projektin riskianalyysi löytyy erillisestä dokumentista. 12
statbeatmobile PROJECT REVIEW iteration 1
statbeatmobile PROJECT REVIEW iteration 1 agenda Projekti Status Käytännöt Tulokset Katsaus eteenpäin PROJEKTI / mikä on statbeat? Sosiaalinen joukkueurheilupalvelu Keskustelu, fanit, kavereiden joukkueet,
Lisätiedotstatbeatmobile FINAL PROJECT REVIEW
statbeatmobile FINAL PROJECT REVIEW agenda Projekti Status Käytännöt Tulokset Katsaus eteenpäin PROJEKTI / mikä on statbeat? Sosiaalinen joukkueurheilupalvelu Keskustelu, fanit, kavereiden joukkueet,
LisätiedotLoppuraportti - StatbeatMOBILE
Loppuraportti - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 21.3.2014 Westin Ensimmäinen versio 1.1 28.3.2014 Westin Täydennystä 1.2 4.4.2014 Pöyry & Westin Luku 1.3 ja muiden lukujen täydennystä
LisätiedotTekninen suunnitelma - StatbeatMOBILE
Tekninen suunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 13.12.2013 Pöyry Alustava rakenne ja sisältö 1.1 22.12.2013 Pöyry Lisätty tekstiä ilmoituksiin, turvallisuuteen ja sisäiseen API:in
LisätiedotOhjelmistojen mallintaminen. Luento 11, 7.12.
Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,
LisätiedotTekninen suunnitelma - StatbeatMOBILE
Tekninen suunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 13.12.2013 Pöyry Alustava rakenne ja sisältö 1.1 22.12.2013 Pöyry Lisätty tekstiä ilmoituksiin, turvallisuuteen ja sisäiseen API:in
Lisätiedot1.1 3.1.2014 Westin Lisätty luku 6, käyttötapauskuvaukset.
Käyttäjävaatimukset Versio Päivämäärä Henkilö 1.0 XX.XX.2013 Kaikki PI-versio. 1.1 3.1.2014 Westin Lisätty luku 6, käyttötapauskuvaukset. 1. Liiketoiminnalliset tavoitteet 2. Käsitteet 3. Yleiskuva järjestelmästä
LisätiedotT Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi
LisätiedotT Projektikatselmus
T-76.115 Projektikatselmus Projektityöryhmä GenCode I3-iteraatio 17.3.2004 Agenda Tavoitteiden toteutuminen (5 min) Resurssien käyttö (5 min) Iteraation tulokset (10 min) Riskit (5min) +Kokemuksia työskentelymenetelmistä
LisätiedotUCOT-Sovellusprojekti. Testausraportti
UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä
LisätiedotTutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
LisätiedotLakki. Lisää ot sik k o osoit t am alla. Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi 2010
Lakki Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy vierailuluentosarja OTM kurssi 2010 2.luento: ohjelmistokehityksen päivärutiinit Lisää ot sik k o osoit t am alla Siitä vain reunasta Miten
LisätiedotLAATURAPORTTI Iteraatio 1
LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja
LisätiedotProjektisuunnitelma. Projektin tavoitteet
Projektisuunnitelma Projektin tavoitteet Projektin tarkoituksena on tunnistaa erilaisia esineitä Kinect-kameran avulla. Kinect-kamera on kytkettynä tietokoneeseen, johon projektissa tehdään tunnistuksen
LisätiedotKaupunginkanslian avoin ohjelmistokehitys, rajapintatyö, syksy kevät Projektitarpeen ja tavoitteiden kuvaus
n avoin ohjelmistokehitys, rajapintatyö, syksy 2018 - kevät 2019 2/7 1 LYHYT KUVAUS 2 PUITESOPIMUKSESTA POIKKEAVAT JA ERIKSEEN SOVITTAVAT KOHDAT NYKYTILA 4 4 TILAUKSEN AIKAJANA 5 KOKOONPANO, OSALLISTUJAT
LisätiedotKÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ
KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset
LisätiedotSEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus
SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Testauksen loppuraportti v. 1.0 Päivitetty 23.4.2001 klo 19:05 Mikko Viljainen 2 (14) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite 1.0
LisätiedotYlläpitodokumentti Mooan
Ylläpitodokumentti Mooan Helsinki 16.08.06 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op/6ov) Projektiryhmä Heikki Aitakangas
LisätiedotTest-Driven Development
Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole
LisätiedotKOODAAKO PROJEKTIPÄÄLLIKKÖ?
KOODAAKO PROJEKTIPÄÄLLIKKÖ? - ROOLIODOTUKSET KETTERISSÄ OHJELMISTOPROJEKTEISSA Mikko Viskari Development Manager Ohjelmistoprojektikokemusta vuodesta 2005 Teknisen projektipäällikön roolissa vuodesta 2011
LisätiedotTestausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
LisätiedotT SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B
T-76.5158 SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B T-76.5158 SEPA - Pariohjelmointi 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 5.12.2006 Tuomas Tolvanen Ensimmäinen
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan
LisätiedotOhjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
LisätiedotAutomaattinen yksikkötestaus
Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä
LisätiedotVERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D
VERSIONHALLINTA PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D Versio Päivä Tekijä Kuvaus 0.1 26.10.2005 Kaarlo Lahtela Ensimmäinen versio 0.2 10.12.2006 Lauri Kiiski Suomennettu 3 (8 ) SISÄLLYS
Lisätiedotdokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant
AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision
LisätiedotProjektisuunnitelma. (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus
Projektisuunnitelma (välipalautukseen muokattu versio) Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena
LisätiedotELM GROUP 04. Teemu Laakso Henrik Talarmo
ELM GROUP 04 Teemu Laakso Henrik Talarmo 23. marraskuuta 2017 Sisältö 1 Johdanto 1 2 Ominaisuuksia 2 2.1 Muuttujat ja tietorakenteet...................... 2 2.2 Funktiot................................
LisätiedotFigure 1: Projektipäälliköt Juha-Pekka Honkavaara ja Juha Mattila
1 Käytettävyysryhmä 1.1 Yleistä Tämän vuoden käytettävyystiimi (Uteam) perustuu kahden viime vuoden pohjalle. Uteam oli toiminnassa ensimmäisen kerran siis lukuvuonna 2005-2006. Uteamin projektiryhmä koostui
LisätiedotTestauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia
Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia Nina Perta, Senior quality consultant Knowit Oy Elina Varteva, QA Specialist Knowit Oy Copyright Knowit Oy 2014 Nina Perta
LisätiedotCS-C2130 / CS-C2140 / CS-E4910 Software Project 1 / 2 / 3 ja Accenture Luento
CS-C2130 / CS-C2140 / CS-E4910 Software Project 1 / 2 / 3 ja Accenture 2016-2017 Luento 14.9.2016 Accenture yleisesti Maailmanlaajuisesti: henkilömäärä: ~ 375 000 toimistoja yli 200 kaupungissa, 120 maassa
LisätiedotTT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)
TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1 Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu
LisätiedotMiten Vero voisi Viestit-Appia hyödyntää? Markku Heikura
Miten Vero voisi Viestit-Appia hyödyntää? 28.3.2017 Markku Heikura Suomi.fi-viestit osana Veron toimintaa Verolle Suomi.fi-viestit on tärkeä osa paperittomuuteen pyrkimisessä. Mobiili viestit-sovellus
LisätiedotAmmattijärjestäjä Aulasvuori Www-projektin kuvaus
Ammattijärjestäjä Aulasvuori Www-projektin kuvaus Minne Seppälä Avat 2014 Dokumentaatio 1 PROJEKTIN KUVAUS... 3 1.1 Projektin aloitus... 3 1.2 Aikataulu... 4 1.3 Kustannusarvio... 4 2 ULKOASU... 5 2.1
LisätiedotVersio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio
Testiraportti 26.2.2006 1/5 - Noheva II Testiraportti Versio Päiväys Tekijä Kuvaus 1.0 26.2.2006 Tikkanen varsinainen versio 1 Yleistä Toteutusvaiheen 2 virallinen testaus on muodostunut automaattisista
LisätiedotESRC:n uusiutumassa olevat kotisivut on toteutettu WordPress-ohjelmalla (WP). Samaa ohjelmaa käyttävät menestyksellä ainakin SSql, HSRC ja JSK.
PIKAOHJEET VIESTIEN KÄYTTÖÖN ESRC:N KOTISIVUILLA Versio 3, 27.12.2006 ESRC:n uusiutumassa olevat kotisivut on toteutettu WordPress-ohjelmalla (WP). Samaa ohjelmaa käyttävät menestyksellä ainakin SSql,
LisätiedotTest-Driven Development
Test-Driven Development Syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole keksiä kaikkia mahdollisia
LisätiedotLaaturaportti [iteraatio 2] Ryhmä 14
Laaturaportti [iteraatio 2] Ryhmä 14 Versio Pvm Tekijä Kuvaus 1.0 2.3.2008 Luukkonen Ensimmäinen versio Sisältö 1. Käytetyt laatumenetelmät... 1 1.1 Automaattiset yksikkötestit, tutkiva testaus ja jatkuva
Lisätiedot58160 Ohjelmoinnin harjoitustyö
58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista
LisätiedotSOVELLUSPROJEKTIN ARVIOINTILOMAKE
SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa
LisätiedotProjektisuunnitelma. KotKot. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Projektisuunnitelma KotKot Helsinki 22.9.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (9 + 1 op) Projektiryhmä Tuomas Puikkonen
LisätiedotC-ohjelmoinnin peruskurssi. Pasi Sarolahti
C! C-ohjelmoinnin peruskurssi Pasi Sarolahti Mitä haluan oppia C-kurssilla? ja miksi? Tutustu lähimpään naapuriin Keskustelkaa miksi halusitte / jouduitte tulemaan kurssille 3 minuuttia è kootaan vastauksia
LisätiedotGood Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä
Good Minton QA Raportti Iteraatio 1 Sulkapalloliiton Kilpailujärjestelmä Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006 12 09 Jani Eränen Alustava DOKUMENTIN TILA: Alustava Valmis Tarkastettu
LisätiedotOnnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti ICT-ajankohtaisseminaari 15.4.2009 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt
LisätiedotLohtu-projekti. Testaussuunnitelma
Lohtu-projekti Testaussuunnitelma Versiohistoria: 1.0 19.2.2003 1. versio Mari 1.1 20.2.2003 Muutoksia Mari 1.2 25.2.2003 Katselmoinnissa esiin tulleet Mari muutokset 1.3 17.3.2003 2. syklissä tehtävät
LisätiedotTyökalut ohjelmistokehityksen tukena
1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan
Lisätiedot4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T
SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen
LisätiedotTapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
LisätiedotScrumin käyttö ketterässä sovelluskehityksessä
Scrumin käyttö ketterässä sovelluskehityksessä 9.4.2008 Janne Kuha Manager, Java Services Descom Oy Janne Kuha Manager, Java Services janne.kuha@descom.fi Kuka? Descom Oy:llä, sitä ennen Wanadu Inc., Mountain
LisätiedotMihin kaikkeen voit törmätä testauspäällikön saappaissa?
Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tieran toiminta perustuu osaamisverkoston rakentamiseen, mikä
LisätiedotData Sailors - COTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................
LisätiedotProjektiryhmä Tete Työajanseurantajärjestelmä. Riskienhallintasuunnitelma
Projektiryhmä Tete Työajanseurantajärjestelmä T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 2(6) Muutoshistoria Versio PVM Tekijä Kuvaus 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja (projektisuunnitelman
LisätiedotTestaussuunnitelma Labra
Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,
LisätiedotLAATUDOKUMENTTI
LAATUDOKUMENTTI LAATUDOKUMENTTI 2 (15) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 11.10.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 17.10.2006 Kaarlo Lahtela Lauri Kiiski 0.3 24.10.2006 Kaarlo Lahtela
LisätiedotTestauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori
Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita
LisätiedotPROJEKTINHALLINTA. Käyttäjälähtöinen suunnittelu
PROJEKTINHALLINTA Käyttäjälähtöinen suunnittelu PROJEKTINHALLINTA OSANA KURSSIA Opettaja: Tomi Jokitulppo email: Tomi.Jokitulppo@metropolia.fi puhelin: 040 5430197 4 opetuskertaa: 2.10., 9.10., 16.10.
LisätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:
LisätiedotL models. Testisuunnitelma. Ryhmä Rajoitteiset
Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Testisuunnitelma Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset
LisätiedotOnnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden
LisätiedotTestilähtöinen ohjelmistokehitys. Testilähtöinen ohjelmistokehitys. TDD Testilähtöinen ohjelmistokehitys. Testi! Testi
Testilähtöinen ohjelmistokehitys Kevät 2008 Jonne Itkonen Jyväskylän yliopisto Testilähtöinen ohjelmistokehitys Test-Driven Development, TDD Tehdään ensin testi, sitten vasta koodi. TDD Testilähtöinen
LisätiedotCOTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................. 1 1.1 Versiohistoria...........................................................................
LisätiedotMaanvuokrausjärjestelmä Mvj. Projektitarpeen ja tavoitteiden kuvaus
Maanvuokrausjärjestelmä Mvj Projektitarpeen ja tavoitteiden kuvaus Helsingin kaupunki TARJOUSPYYNTÖ 2 (10) LYHYT KUVAUS 3 PUITESOPIMUKSESTA POIKKEAVAT ja ERIKSEEN SOVITTAVAT KOHDAT 3 NYKYTILA - KOKEILUVAIHEEN
LisätiedotKetteryys kokeilemalla. Leo Malila Kehittämispäällikkö, Kela
Ketteryys kokeilemalla Leo Malila Kehittämispäällikkö, Kela 1.11.2016 Agenda Kelan ICT Ketteryys tavoitteena Teetetyn tutkimuksen ja sen kohteen esittely Havaintoja tutkimuksen perusteella Kelan ketteryys
LisätiedotConvergence of messaging
Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO
LisätiedotXDW-projektissa rakennetut palvelut
XDW-projektissa rakennetut palvelut Korkeakoulujen KOTA-AMKOTA seminaari 23. 24.9.2010 Manne Miettinen CSC Tieteen tietotekniikan keskus Oy CSC IT Center for Science Ltd. RAKETTI-hankkeen tavoite korkeakouluja
LisätiedotProjektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus
Projektisuunnitelma Vesiprosessin sekvenssiohjelmointi ja simulointiavusteinen testaus Ville Toiviainen Tomi Tuovinen Lauri af Heurlin Tavoite Projektin tarkoituksena on luoda valmis sekvenssiohjelma säätötekniikan
LisätiedotDoodle helppoa aikatauluttamista
Doodle helppoa aikatauluttamista Kuinka käytän Doodlea? -vaiheittainen opas käyttöön ja aikataulukyselyn luomiseen http://www.doodle.com/ Doodle on ohjelma joka auttaa sinua aikatauluttamaan kokouksia
LisätiedotTestaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille
1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei
LisätiedotVerkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008
Verkkopokerijärjestelmä Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008 Projektiryhmä Samuli Aalto-Setälä Jukka Kekälainen Jarno Kyykkä Mika Mielonen Mårten Smeds Otto Waltari Ohjaaja
LisätiedotMenetelmäraportti Ohjelmakoodin tarkastaminen
Menetelmäraportti Ohjelmakoodin tarkastaminen Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5
LisätiedotWCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma
TKK/DISKO/Tik-76.115 WCLIQUE Projektiryhmä Clique http://www.hut.fi/jekahkon/wclique/testplan.html WCLIQUE Ohjelmistoprojekti Projektiryhmä Clique: Janne Dufva, 75008T, email: janne.dufva@nokia.com, 75014C,
LisätiedotOhjelmistoprojekti projektipäällikön näkökulmasta
Ohjelmistoprojekti projektipäällikön näkökulmasta Juhana Huotarinen Build Success Juhana Huotarinen, DI Opiskellut TTY:llä vuosina 2000-2006 Työura Goforessa vuodesta 2005 Ohjelmistosuunnittelija (JavaEE-teknologiat)
LisätiedotProjektityö
Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:
LisätiedotT Testiraportti - integraatiotestaus
T-76.115 Testiraportti - integraatiotestaus 16. huhtikuuta 2002 Confuse 1 Tila Versio: 1.1 Tila: Päivitetty Jakelu: Julkinen Luotu: 19.03.2002 Jani Myyry Muutettu viimeksi: 16.04.2002 Jani Myyry Versiohistoria
LisätiedotMobiililaitteiden ja sovellusten tietoturvallisuus mihin tulee kiinnittää huomiota?
Mobiililaitteiden ja sovellusten tietoturvallisuus mihin tulee kiinnittää huomiota? Sisällys Tietoturvauhkia Sovellusten tietoturvallisuus» 1. Sovelluskaupat» 2. Sovelluksen tekijä» 3. Käyttöoikeudet»
LisätiedotMenetelmäraportti - Konfiguraationhallinta
Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1
LisätiedotOhjelmistotekniikka - Luento 2
Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit
LisätiedotProjektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti
Projektiryhmä Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson T-76.115 Tietojenkäsittelyopin ohjelmatyö 2(8)
LisätiedotSisällys. 2 Aloittaminen. 4 Ominaisuudet esimiehet esimerkissä. 5 Työajan mobiilikirjaus
Sisällys 2 Aloittaminen 2 Ominaisuudet tuotantotyöntekijä esimerkissä 3 Ominaisuudet toimistotyöntekijä esimerkissä 4 Ominaisuudet esimiehet esimerkissä 5 Ominaisuudet pääkäyttäjänä 5 Työajan mobiilikirjaus
LisätiedotAjankäytön suunnittelu opiskelussa. SCI-A0000 Johdatus opiskeluun Susanna Reunanen 29.10.2015
Ajankäytön suunnittelu opiskelussa SCI-A0000 Johdatus opiskeluun Susanna Reunanen 29.10.2015 Sisältö Ajankäytön suunnittelu Ajankäytön vinkkejä Esimerkkejä ajankäytön suunnitteluun Linkkejä 30.10.2015
LisätiedotOhjelmistotekniikka - Luento 2 Jouni Lappalainen
Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento
LisätiedotConcurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo
Concurrency - Rinnakkaisuus Group: 9 Joni Laine Juho Vähätalo Sisällysluettelo 1. Johdanto... 3 2. C++ thread... 4 3. Python multiprocessing... 6 4. Java ExecutorService... 8 5. Yhteenveto... 9 6. Lähteet...
LisätiedotProject group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson T-76.115 Software project 2(5) Muutosloki
LisätiedotMuistitko soittaa asiakkaallesi?
webcrm Finland 1 webcrm Finland Muistitko soittaa asiakkaallesi? Riippumatta siitä, oletko myyntipäällikkö, markkinoija vai työskenteletkö HR tehtävissä, voit käyttää CRM ratkaisua erilaisiin tarpeisiin.
LisätiedotStrateginen tekijä Trello. Ville Tura, projektipäällikkö Tamora Oy
Strateginen tekijä 25.9.2017 Trello Ville Tura, projektipäällikkö Tamora Oy Parituntisen teemoja Kertauksena Trello työkaluna Trellon peruskäyttö - mihin kaikkeen Trelloa voi käyttää? Trellon perustoiminnot,
LisätiedotTieto Edu. Tieto Edun mobiiliversiota voi käyttää Android- ja IOs-laitteissa ja web-version käyttöön suosittelemme joko Crome- tai Firefox-selainta.
Tieto Edu Hoitoaikavaraukset ja äkillisten poissaolojen ilmoittaminen 14.10. alkaen. 14.10. hoitoaikavaraukset ilmoitettava 7.10. klo 24 mennessä. Sovelluksen voi ladata heti. DaisyNet poistuu käytöstä.
LisätiedotToteutusvaihe T3 Digi-tv: Edistymisraportti
Toteutusvaihe T3 Digi-tv: Edistymisraportti Sisällysluettelo 1. Projektin tila...3 Dtv: Work done per Person (current phase)...3 Dtv: Work done per Worktype (current phase)...3 2. Suoritetut tehtävät...4
LisätiedotKuva: Ilpo Okkonen
OodiHOPS OHJAAJAN OHJE 14.2.2017 Kuva: Ilpo Okkonen OodiHOPS Oulun yliopistossa Oulun yliopiston koulutusneuvosto on päättänyt, että OodiHOPS-toiminto otetaan käyttöön vähintään aloittavilla opiskelijoilla
LisätiedotTestaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan
LisätiedotCT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)
LisätiedotT Testiraportti - järjestelmätestaus
T-76.115 Testiraportti - järjestelmätestaus 18. huhtikuuta 2002 Confuse 1 Tila Versio: 1.0 Tila: Päivitetty Jakelu: Julkinen Luotu: 18.04.2002 Jani Myyry Muutettu viimeksi: 18.04.2002 Jani Myyry Versiohistoria
LisätiedotT 76.115 Tietojenkäsittelyopin ohjelmatyö Hirviöryhmä loppukatselmointi. Hirviö. Projektikatselmointi
Hirviö Projektikatselmointi Mikä Hirviö on? Hajautettu muistikirja Professoreille Muistiinpanoja keskusteluista opiskelijan kanssa Diplomitöiden ja jatko opintojen seuranta Raportointi Opetushenkilökunnalle
LisätiedotTDD Käytännössä Todellinen työkalu vai lehmipoikien laukkaa? Harri Kulmala Solita Oy
www.solita.fi solita@solita.fi TDD Käytännössä Todellinen työkalu vai lehmipoikien laukkaa? Harri Kulmala Solita Oy 1 TDD Käytännössä Test Driven Development yleisesti Lupaukset Esimerkki Projektin ja
LisätiedotOnnistunut Vaatimuspohjainen Testaus
Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen
LisätiedotOhje vanhemmille - näin alkuun Päikyssä
Ohje vanhemmille - näin alkuun Päikyssä Tunnuksen aktivointi ensimmäinen sisäänkirjautuminen Päikkyyn Huoltajana sinulle on luotu tunnus varhaiskasvatusyksikön toimesta matkapuhelinnumerosi perusteella.
LisätiedotA14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen
1 AS-0.3200 Automaatio- ja systeemitekniikan projektityöt A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen Projektisuunnitelma Tommi Salminen, Hanna Ukkola, Olli Törmänen 19.09.2014 1 Projektin
LisätiedotT Ohjelmistokehitysprojekti I - Iteraatiosuunnitelma (I2)
T-76.4110 Ohjelmistoprojekti I 25.2.2006 T-76.4115 Ohjelmistokehitysprojekti I - Iteraatiosuunnitelma (I2) Versio Päiväys Muokkaaja Kuvaus 2.0 25.2.2006 Markus Kattilamäki Päivämäärien tarkennus, viimeistely
Lisätiedotohjeita kirjautumiseen ja käyttöön
ohjeita kirjautumiseen ja käyttöön Kirjautumisesta Opiskelijat: kirjaudu aina tietokoneelle wilmatunnuksella etunimi.sukunimi@edu.ekami.fi + wilman salasana Opettajat: kirjaudu luokan opekoneelle @edu.ekami.fi
Lisätiedot