SEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant
|
|
- Sari Alanen
- 6 vuotta sitten
- Katselukertoja:
Transkriptio
1 AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 10
2 Dokumenttihistoria Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä Ensimmäinen versio (kuvaus menetelmästä). Rauli Ikonen Päivitetty dokumenttia johdannon ja rakenteen osalta. Pasi Kallioniemi Lisätty I1-vaiheen teksti Rauli Ikonen Dokumentin rakennetta muutettu Esa Mommo I2-vaiheen kokemuksista kompleksisuusmittarien näkökulmasta Pasi Kallioniemi I2-koodikatselmoinneista ja FindBugsista Rauli Ikonen Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Rauli Ikonen Pasi Kallioniemi Tehtävä Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Seppo Sahi Tehtävä Mentor Aihe: RI & PK Sivu 2 of 10
3 Sisällysluettelo 1. Esittely Tarkoitus Menetelmän kuvaus Viitteet Käyttöönotto Kokemukset ja muutokset PP-vaihe I1-vaihe I2-vaihe FD-vaihe Yhteenveto...9 Aihe: RI & PK Sivu 3 of 10
4 1. Esittely 1.1 Tarkoitus Tämän dokumentin tarkoitus on kuvata AgilElephant projektissa käytettyä SEPA (Software Engineering Practice Assignment)-menetelmää. Menetelmä esitellään ja perustellaan luvussa 1. Luku 2 sisältää suunnitelmat menetelmän käyttöönotolle. Lukuun 3 kirjataan kokemuksia ja havaintoja menetelmän hyödyistä ja sopivuudesta projektin tarpeisiin. 1.2 Menetelmän kuvaus SEPA aiheenamme on staattiset metodit koodianalysoinnnissa. Staattinen koodianalysointi tarkoittaa ohjelmakoodin analysointia ilman että koodi ajetaan. Mahdollisia analysoitavia asioita ovat koodin laatu (rakenne, koko, viittaukset moduulista toiseen jne..), ohjelmakoodin virheet sekä koodin oikeellisuus tehtävien toiminnallisuuksien kannalta. Yleisesti staattista koodianalyysiä voidaan tehdä automatisoidusti työkaluilla tai ihmisten tekemänä, esim. koodikatselmuksilla. Automatisoidussa staattisessa analysoinnissa käytetään työkaluja jotka laskevat erilaisia mittareita ohjelmakoodista ja luovat niistä raportteja varoittaen ohjelmakoodin huonosta laadusta tai virheistä. Käytettyjä mittareita ovat mm. metodissa/luokassa olevan koodin rivimäärä, yhden luokan viittausten määrä moduulista toiseen, sekä McCaben syklomaattinen kompleksisuus (ohjelmakoodin haarautumisluku). Myös bugeja voidaan analysoida koodista ohjelmilla jotka esim. ensin tekevät koodista vuokaavion ja analysoivat tämän avulla onko mahdollisuuksia ikuisiin silmukoihin tai rinnakkaisuusongelmiin. Raporttien tekeminen ei ole ainoa vaihtoehto automatisoinnille, sillä nykyisin osa työkaluista pystyy integroitumaan käytettävään kehitysympäristöön ja antamaan ohjelmoijalle suoraan palautetta hänen kirjoittaessaan koodia. Koodia ei välttämättä voida analysoida kattavasti automatisoituna. Tällöin analysointiin käytetään ihmisiä. Koodikatselmus on tekniikka jolla pystytään levittämään tietämystä koodien toiminnasta usealle henkilöille projektissa, samalla varmistaen että tehty toiminnallisuus on selkeä sekä toimiva. Uuden ominaisuuden katselmoinnissa valitaan joukko ihmisiä tekemään katselmointia. Tällöin henkilö(t) käyvät tehdyn ominaisuuden lävitse tekijän opastuksella, ja he esittävät tekijälle kysymyksiä epäselvistä kohdista ja kommentoivat koodia. Toiminta perustuu siihen että tekijästä tulee helposti sokea omille virheilleen ja on mahdollisesti jumittunut tottumuksesta johonkin huonoon koodaustyyliin, joten ulkopuolisten ihmisten antama palaute toimii kehittävänä tekijänä virheiden paljastuksen ohella. Valitsimme tämän aiheen siksi että koimme sen tarjoavan hyvän ja realistisen mahdollisuuden parantaa ohjelmakoodin laatua tällä kurssilla tehtävässä projektissa. Lisäksi staattinen koodianalysointi on mielestämme mielenkiintoinen alue johon kumpikaan meistä ei ole vielä työelämässä päässyt tutustumaan. Toivomme että asia osoittautuu vaivan arvoiseksi ja tämän kurssin jälkeen osaamme soveltaa sitä työelämässä menestyksekkäästi. Aihe: RI & PK Sivu 4 of 10
5 1.3 Viitteet Staattinen analyysi: Finding faults in multi-threaded programs, Cyrille Artho 2001; Koodikatselmukset: Practical Software Testing. Ilene Burnstein Aihe: RI & PK Sivu 5 of 10
6 2. Käyttöönotto Tulemme integroimaan staattisia koodianalysointityökaluja kääntöympäristöömme niin, että työkalut ajetaan automaattisesti päivittäisen käännöksen yhteydessä ja saadut tulokset liitetään kääntöjärjestelmän luomaan raporttiin. Järjestelmään integroitavat työkalut ovat FindBugs ja JavaNcss. Edellinen hakee koodista automaattisesti yleisiä ohjelmointivirheitä ja jälkimmäinen laskee koodista kompleksisuustunnuslukuja. Lisäksi tulemme ajamaan satunnaisesti JLint-työkalua ja mahdollisesti Teaminaboxia. Näitä ei kuitenkaan integroida buildijärjestelmään. Sen lisäksi, että FindBugsin löytämät virheet korjataan, tullaan virheet myös kategorisoimaan asteikolla vähäinen (ei mahdollisesti lainkaan virhe), normaali ja vakava. Lisävirheiden löytämiseksi tulemme suorittamaan koodista kaksi kahden tunnin koodikatselmointia, toinen vaiheen I1 ja toinen vaiheen I2 lopussa. Katselmoinneissa löytyneet virheet kategorioidaan kuten automaattityökalujen löytämät virheet. Vaiheen I2 jälkeen tulemme analysoimaan löytyneet ongelmat, käyttäen pohjana koodin kompleksisuusmittareita: Korreloiko löytyneiden virheiden määrä suhteessa luokkien ja metodien kompleksisuuksiin. Ottaen huomioon kehitettävän järjestelmän suhteellisen pienen koon ja staattiseen koodianalyysiin käytettävissä olevan varsin rajallisen ajan, on mahdollista, että virheitä ei löydy niin paljon, että niistä voisi tehdä mielekästä tilastollista analyysiä. Jos näin käy rajoittuu menetelmän hyöty lähinnä koodin parempaan laatuun sekä raportointiin kokemuksista staattisista koodianalyysityökaluista yleensä. Virheiden korjaamisen ja kompleksisuuteen pohjautuvan analysoinnin lisäksi tulemme vaiheen I2 loppupuolella käyttämään noin neljä tuntia koodin refaktorointiin. Refaktoroitavat osat valitaan JavaNcss:n tuottamien kompleksisuusmittarien ja oman harkinnan pohjalta; refaktoroitavaksi päätyvät kompleksisuudeltaan suurimmat metodit mitkä vaikuttavat myös asianomaisista kaikkein vaikeaselkoisimmilta. Tälläkin pyritään luonnollisesti ohjelman laadun ja jatkokehityksen parannettavuuteen. Aihe: RI & PK Sivu 6 of 10
7 3. Kokemukset ja muutokset 3.1 PP-vaihe Staattisia menetelmiä ei sovellettu vielä tässä vaiheessa. 3.2 I1-vaihe I1-vaiheessa integroitiin sekä JavaNcss että FindBugs buildijärjestelmän osaksi. Järjestelmä ajaa molemmat työkalut joka yö normaalin käännöksen yhteydessä ja laittaa tulokset esille osoitteeseen Koska järjestelmän todellinen implementointi alkoi vasta iteraation aivan loppupuolella, ei tämän iteraation puitteissa vielä voitu tehdä mitään erityistä analyysiä virheistä tai luokkien kompleksisuuksista. Ainakin FindBugs kuitenkin osoitti jo hyödyllisyytensä löytämällä kolme todellista virhettä (SA, UwF, DE) sekä neljä validia huomautusta huonosta rakenteesta ja tehottomasta koodista (EI, EI2, Dm, RCN). Kaikkien löydettyjen varsinaisten virheiden vakavuusaste oli normaali. Kaksi rakennevirhettä (EI, EI2) esiintyi yhteensä 22 kertaa. (Tarkempi listaus virhekoodeista ja virheistä lisätään I2-vaiheessa.) I1-vaiheessa oli alkuperäisen suunnitelman mukaan myös tarkoitus suorittaa koodikatselmus. Johtuen implementaation myöhäisestä alkamisajankohdasta ei koodikatselmointia ehditty suorittaa tässä vaiheessa. I1-vaiheen koodikatselmus siirretään tästä johtuen I2-vaiheen puoliväliin ja I2-vaiheen loppuun suunniteltu katselmus suoritetaan FD-vaiheen puolivälissä. 3.3 I2-vaihe I2-vaiheessa järjestelmän laajentuessa tarkkailimme valitsemiamme mittareita. Kompleksisuusluvut näyttivät hyvin pitkälti pysyvän maltillisissa arvoissa. Olimme sopineet alustavasti että kompleksisuusarvot jotka ovat yli 20, niitä seurataan tarkemmin (JavaNcssraporteissa metodit on järjestetty kompleksisuuden mukaan ja yli 20 menevät arvot näkyvät punaisina). Kahdenkymmenen raja perustui SEI:n yhdelle suositusmallille kompleksisuuden ja mahdollisen riskin vertaamiselle. (Lähde: Cyclomatic Complexity Risk Evaluation 1-10 a simple program, without much risk more complex, moderate risk complex, high risk program Aihe: RI & PK Sivu 7 of 10
8 greater than 50 untestable program (very high risk) Mutta kuitenkaan mitään ehdottomia ala/ylärajoja emme mielestämme voineet määrittää koodeille koska kyseinen mittari on hyvinkin tapauskohtainen ja muutenkin näihin ohjearvoihin pitää suhtautua mielestämme varauksellisesti. Perusteluksi tälle olivat omat kokemuksemme ohjelmistojenkehityksessä ja erityisesti sen tilannekohtaisesta vaihtelevuudesta. Muutamat metodit I2-vaiheen kuluessa olivat kylläkin arvoiltaan jo paljon ylitse kahdenkymmen rajan: BacklogItemManagerBean.changeBacklogItemStatus(), CCN=48 CycleManagerBean.getPortfolioReleases(), CCN=33 GetPortfolioDetails.doStartTag(), CCN=29 Tarkastelun jälkeen emme kuitenkaan päätyneet refaktoroimaan mitään näistä metodeista mm. seuraavista syistä johtuen. changebacklogitemstatus on metodi, jota kutsutaan RMI-rajapinnan lävitse web-palveluista. Sen tarkoituksena on muuttaa yhden backlogitemin tilaa toiseen jos annettu tila on mahdollinen. Metodissa on hyvin paljon lisätarkistuksia parametrien oikeellisuudesta ja annetun tilan vaihdoksen mahdollisuudesta. Ne eivät kuitenkaan haarauta ohjelman tilaa metodin sisällä vaan suuri osa näistä ehdoista aiheuttaa poistuman metodista virheilmoituksen kera. Kyseessä on siis enemmänkin hyvin vikasietoinen koodi kuin erittäin monimutkainen. getportfolioreleases-metodi sisälsi myös kohtalaisesti tarkistuksia, mutta korkeaan lukuun sisältyi muu syy. Kyseinen metodi hakee kaikki release-tiedot jotka liittyvät yhteen portfolioon. Tämä olisi kuitenkin ollut yhtenä tietokantahakuna todella monimutkainen joten koodissa oli päädytty ratkaisemaan tämä ohjelmallisesti, eli järjestämään ja filtteroimaan tulosjoukko ohjelmakoodissa. Eli loppujen lopuksi tässä metodissa oli tehty tietoinen valinta ratkaisun monimutkaisuudesta, mutta silti se nähtiin kannattavammaksi tavaksi tehdä näin. dostarttag-metodissa oli kyseessä hausta ja haun tuloksien tallentamisesta jsp-sivun käytettäväksi. Tässä toistui sama syndrooma kuin changebacklogitemstatus-metodissa, eli tehtiin hyvin paljon tarkistuksia parametrien arvoista. Lopuksi voidaan todeta että yleisestikin tuntuu siltä että kompleksisuusmittarit voivat helposti saada kohtalaisen suuria lukuja web-pohjaisessa ohjelmoinnissa jossa täytyy tarkistaa käyttäjän antamien parametrien kelpoisuutta, muokata niitä esitettävään muotoon, sekä tehdä myös sisäistä virhetarkistusta. Edellä mainittujen korkean kompleksisuuden omaavien metodien lisäksi katselmoimme useita muita kohtia koodista. Valitut kohdat olivat lähinnä satunnaisia pyrkien saamaan mahdollisimman suuren variaation. Kirjattaessa virheitä pyrittiin kiinnittämään huomiota virheen sisältävän luokan ja metodin kompleksisuusmetriikoihin mahdollisen korrelaation havaitsemiseksi. Katselmoinnin yhteydessä löytyi seitsemän virhettä. Virheistä kolme oli vakavia ja ne aiheuttivat järjestelmän kannalta vakavaa virheellistä toimintaa. Kaksi virhettä eivät aiheuttaneet käyttäjille näkyviä virheitä, vaan aiheuttivat turhan tiedon tallentamista tietokantaan. Kaksi virhettä ei nykyisellään aiheuttanut lainkaan virhettä, mutta olisivat voineet helposti johtaa kyseessä olleen ominaisuuden toimimattomuuteen toisaalla tapahtuvien muutosten johdosta. Aihe: RI & PK Sivu 8 of 10
9 Virheiden esiintymispaikan ja kompleksisuusasteen välillä ei ollut havaittavissa mitään korrelaatiota. Toki otoskin jäi niin pieneksi, ettei mitään tilastollista yhteyttä olisi voinut kovin vakaalla pohjalla esittää. Sen sijaan koodin kirjoittajan ja virhetodennäköisyyden välillä oli selvästi havaittava yhteys. Ohjelmointia suorittaneista henkilöistä yhdellä oli vastaavista järjestelmistä paljon kokemusta, kahdella jonkin verran ja kolmella varsin vähän. Kaikki virheet löytyivät niiden henkilöiden kirjoittamista koodeista kenen kokemus vastaavista järjestelmistä tai yleensä käytetystä ohjelmointikielestä tai ohjelmoinnista olivat vähäisimmät. Koodikatselmusten yhteydessä tuli myös ilmeiseksi se, että nyt kehitettävä ohjelmisto ei sovellu parhaalla mahdollisella tavalla koodikatselmointiin. Todennäköisimpiä virhelähteitä ovat ongelmat parametrien välityksessä HTML-sivuilta Servleteille ja toisinpäin, sekä tageilta jspsivuille. Myös ongelmat HQL (SQL) queryissä ovat varsin todennäköinen ongelmalähde. Mitään näistä ongelmista ei ole erityisen helppoa havaita lukemalla koodia läpi, koska virheiden havaitseminen vaatii monesti usean eri tiedoston samanaikaista tutkimista sekä keskittymistä logiikan kannalta epäolennaisiin asioihin kuten oikeinkirjoitukseen. FindBugs löysi I2-iteraation aikana kuusi virhettä. Kaksi Dm virhettä, kaksi SBSC virhettä, yhden UrF virheen, sekä yhden DE virheen. Virhekoodit selitykseen on listattu liitteessä A. Tällä kertaa FindBugsin ilmoittamat virheet eivät paljastaneet yhtään vakavaa, todellista ongelmaa koodissa. Ilmoitukset olivat toki aiheellisia ja ne korjattiin/korjataan, mutta varsinaista vaaraa niistä ei ollut. FindBugsin osalta tulos oli pienoinen pettymys; hyvän alun jälkeen sen toivottiin paljastavan useitakin todellisia ongelmia, mutta näin ei käynyt. FindBugs on kuitenkin edelleen käytön helppouteen ja nopeuteen suhteutettuna hyvä lisätyökalu virheiden etsimisessä. FD-vaiheessa tullaan vielä suorittamaan koodikatselmointia osalle sen aikana tuotetusta koodista. Katselmukset pyritään suuntaamaan I2-vaiheen kokemusten pohjalta enemmän koodin kirjoittajan kuin koodin kompleksisuusasteen mukaan. Myös FindBugsin käyttämistä tullaan jatkamaan ja JavaNcss-metriikoitakin kerätään, vaikkakaan niille ei tulla antamaan kovin paljon painoarvoa. 3.4 FD-vaihe 3.5 Yhteenveto Aihe: RI & PK Sivu 9 of 10
10 Liite A: FindBugs virhekoodit Koodi Dm SBSC UrF UwF EI EI2 RCN Selite Turha new String( string ) kutsu pelkkä string tekee saman (performance) Stringien yhdistämistä +-operaattorilla loopissa (performance) Lukematon muuttuja; muuttuja on esitelty mutta sitä ei käytetä koskaan Kirjoittamaton muuttuja; muuttuja on esitelty mutta sen arvoa ei koskaan aseteta Epäsuora mahdollisuus muuttaa olion tilaa esim. palauttamalla suora viite olion sisältämään toiseen olioon minkä tilaa voidaan muuttaa Epäsuora mahdollisuus muuttaa olion tilaa esim. antamalla parametrina suora viite olioon toiselle oliolle mikä tallentaa vain viitteen null-tarkistus oliolle minkä null-statusta ei ole tarkistettu aiemmin koodissa; tarkitus on joko turha tai se pitäisi olla jo aikaisemmin SA Arvon asettaminen arvoon itseensä; x = x; DE Mahdollinen exceptionin huomoimatta jättäminen Aihe: RI & PK Sivu 10 of 10
SEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant Versio: V0.2
AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 7 Dokumenttihistoria Muutoshistoria Revision päiväys: 1.11.2004
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant
AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 11 Dokumenttihistoria Muutoshistoria Revision Numero Revision
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ä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 päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: 26.10.2004 Projekti : AgileElephant Versio: V0.9
AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 6 Dokumentti Historia Revisio Historia Revision päiväys: 26.10.2004
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ätiedotSEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant Versio: V0.93
AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 7 Dokumentti Historia Revisio Historia Revision päiväys: 29.11.2004
LisätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys
LisätiedotSEPA päiväkirja. Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T Ohjelmistoprojekti I
SEPA päiväkirja Aihe: Staattiset menetelmät Tekijät: Mikko Halttunen 58198B, Mikko Närjänen 58122B Ryhmä: Neptune T-76.4110 Ohjelmistoprojekti I Sisällysluettelo Sisällysluettelo...2 1. Johdanto...3 2.
LisätiedotSEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant
AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 8 Dokumentti Historia Revisio Historia Revision Numero Revision
Lisätiedot0.47 27.11.2005 Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen
Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 24.10.2005 Elina Kontro Laatuasiat siirretty omaan dokumenttiin jatkotyöstetty 0.2 27.10.2005 Santeri Saarinen Bugien elinkaari yms. asioita jatkettu 0.3 28.10.2005
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ätiedotSEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant
AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 8 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys
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ä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ä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ätiedotYlläpitodokumentti. Boa Open Access. Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Ylläpitodokumentti Boa Open Access Helsinki 2.5.2006 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Ilmari
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ätiedotTestaussuunnitelma. Dokumentti: Testaussuunnitelma.doc Päiväys: Projekti: AgileElephant
AgilElephant Tekijä: Petri Kalsi ja Heikki Salminen Omistaja: ElectricSeven Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 1 / 11 Dokumenttihistoria Muutoshistoria Revision Numero Revision Päiväys Yhteenveto
LisätiedotTestaussuunnitelma. Dokumentti: Testaussuunnitelma.doc Päiväys: Projekti: AgileElephant Versio: V0.4
AgilElephant Tekijä: Petri Kalsi ja Heikki Salminen Omistaja: ElectricSeven Dokumentti:.doc Päiväys: 30.11.2004 Aihe: Sivu 1 / 11 Dokumenttihistoria Muutoshistoria Revision päiväys: 30.11.2004 Seuraavan
LisätiedotT-76.5158 SEPA päiväkirja
T-76.5158 SEPA päiväkirja Ryhmä 14 Automatisoitu yksikkötestaus Mikko Luukkonen, 60549T Lauri Helkkula, 62820H Matti Eerola, 60686A Versiohistoria Versio Pvm Tekijä(t) Kuvaus 0.3 25.11.2007 Luukkonen,
LisätiedotAgilElephant ja CruiseControl
AgilElephant ja CruiseControl Tekijä: Juha Kaarlas Omistaja: ElectricSeven Aihe: CruiseControl ja AgilElephant Sivu 1 of 9 Dokumentti Historia Muutoshistoria Revision Revision Yhteenveto muutoksista Revision
LisätiedotTarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen
Tarjolla tänää: Ohjelmiston toteutuksesta JOT2007 CRC-kortit Testilähtöinen kehittäminen Uudelleenrakentaminen Voisiko ohjelmointi olla sittenkin suunnittelua? Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit
LisätiedotTestausraportti. Dokumentti: Testausraportti_I2.doc Päiväys: Projekti : AgileElephant
AgilElephant I2 Tekijä: Heikki Salminen Omistaja: ElectricSeven Aihe: Sivu 1 / 8 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä 1.0 7.2.2004
Lisätiedot11/20: Konepelti auki
Ohjelmointi 1 / syksy 2007 11/20: Konepelti auki Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/11 Tämän luennon
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ätiedotT SEPA - päiväkirja: Design Patterns. ETL työkalu
T-76.115 SEPA - päiväkirja: Design Patterns ETL työkalu Versio Päivämäärä Tekijä Kuvaus 1.0 25.10.2004 Jani Honkanen PP-vaiheen jälkeinen versio 1,1 26.11.2004 Mika Suvanto I1- vaiheen kokemuksia lisätty
LisätiedotProject group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Versionhallinta BitKeeper-työkalun avulla Tuomas Heino Muutosloki Versio Pvm Tekijä Kuvaus 1.0 01.12.2003
LisätiedotSEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T. Sisällysluettelo. 1 Johdanto. 2 SEPA harjoittelu käytännössä.
Sivu 1 (5) SEPA: Staattiset menetelmät Timo Sallinen, 51134F & Risto Kunnas, 50498T Versio Päiväys Tekijä Kuvaus 0.1 27.10.2004 Timo Sallinen Ensimmäinen versio 1.0 31.10.2004 Timo Sallinen Korjauksia,
LisätiedotCOTOOL dokumentaatio Testausdokumentit
Table of Contents Testausraportti.............................................................................. 1 1 Tiivistelmä...............................................................................
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ätiedotCOTOOL dokumentaatio SEPA: Refaktorointi
Table of Contents Refaktorointi................................................................................ 1 1 Tehtävänanto.............................................................................
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ä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 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä
LisätiedotLaadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy
Laadunvarmistuksen suunnitelma Ryhmä ExtraTerrestriaLs Aureolis Oy Versio Päiväys Tekijä Kuvaus 1.0 8.11.2004 Risto Kunnas Ensimmäinen versio 1.1 8.11.2004 Risto Kunnas Korjauksia 1.2 9.11.2004 Mika Suvanto
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ä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ä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ätiedot15. Ohjelmoinnin tekniikkaa 15.1
15. Ohjelmoinnin tekniikkaa 15.1 Sisällys For-each-rakenne. Lueteltu tyyppi enum. Override-annotaatio. Geneerinen ohjelmointi. 15.2 For-each-rakenne For-rakenteen variaatio taulukoiden ja muiden kokoelmien
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ätiedotGroovy. Niko Jäntti Jesper Haapalinna Group 31
Groovy Niko Jäntti Jesper Haapalinna Group 31 Johdanto Groovy on Apachen kehittämä Javaan perustuva dynaaminen oliopohjainen ohjelmointikieli. Kielen kehitys alkoi vuonna 2003, versio 1.0 julkaistiin 2007
Lisätiedot1 Tehtävän kuvaus ja analysointi
Olio-ohjelmoinnin harjoitustyön dokumentti Jyri Lehtonen (72039) Taneli Tuovinen (67160) 1 Tehtävän kuvaus ja analysointi 1.1 Tehtävänanto Tee luokka, jolla mallinnetaan sarjaan kytkettyjä kondensaattoreita.
LisätiedotPong-peli, vaihe Aliohjelman tekeminen. Muilla kielillä: English Suomi. Tämä on Pong-pelin tutoriaalin osa 3/7. Tämän vaiheen aikana
Muilla kielillä: English Suomi Pong-peli, vaihe 3 Tämä on Pong-pelin tutoriaalin osa 3/7. Tämän vaiheen aikana Jaetaan ohjelma pienempiin palasiin (aliohjelmiin) Lisätään peliin maila (jota ei voi vielä
Lisätiedot1. Olio-ohjelmointi 1.1
1. Olio-ohjelmointi 1.1 Sisällys Olio-ohjelmointi on eräs ohjelmointiparadigma. Olio-ohjelmoinnin muotoja. Ohjelmiston analyysi ja suunnittelu. Olioparadigman etuja ja kritiikkiä. 1.2 Ohjelmointiparadigmoja
LisätiedotJärjestelmäarkkitehtuuri (TK081702)
Järjestelmäarkkitehtuuri (TK081702) yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,
Lisätiedot4. Luokan testaus ja käyttö olion kautta 4.1
4. Luokan testaus ja käyttö olion kautta 4.1 Olion luominen luokasta Java-kielessä olio määritellään joko luokan edustajaksi tai taulukoksi. Olio on joukko keskusmuistissa olevia tietoja. Oliota käsitellään
LisätiedotTaulukot. Jukka Harju, Jukka Juslin 2006 1
Taulukot Jukka Harju, Jukka Juslin 2006 1 Taulukot Taulukot ovat olioita, jotka auttavat organisoimaan suuria määriä tietoa. Käsittelylistalla on: Taulukon tekeminen ja käyttö Rajojen tarkastus ja kapasiteetti
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ä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ätiedotOhjelmointi 1 / syksy /20: IDE
Ohjelmointi 1 / syksy 2007 10/20: IDE Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/8 Tämän luennon rakenne
LisätiedotYksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }
Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.
Lisätiedot8/20: Luokat, oliot ja APIt
Ohjelmointi 1 / syksy 2007 8/20: Luokat, oliot ja APIt Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/8 Kohti
LisätiedotSisällys. Yleistä attribuuteista. Näkyvyys luokan sisällä ja ulkopuolelta. Attribuuttien arvojen käsittely aksessoreilla. 4.2
4. Attribuutit 4.1 Sisällys Yleistä attribuuteista. Näkyvyys luokan sisällä ja ulkopuolelta. Attribuuttien arvojen käsittely aksessoreilla. 4.2 Yleistä Luokan lohkossa, mutta metodien ulkopuolella esiteltyjä
LisätiedotGIS-automatisointi ja ohjelmointi/skriptaus. Harri Antikainen
GIS-automatisointi ja ohjelmointi/skriptaus Harri Antikainen Mistä nyt puhutaan? Automatisointi: Mikä tahansa tapa teettää tietokoneella asioita ilman että käyttäjän tarvitsee tehdä muuta kuin laittaa
Lisätiedot15. Ohjelmoinnin tekniikkaa 15.1
15. Ohjelmoinnin tekniikkaa 15.1 Sisällys For-each-rakenne. Geneerinen ohjelmointi. Lueteltu tyyppi enum. 15.2 For-each-rakenne For-rakenteen variaatio taulukoiden ja muiden kokoelmien silmukoimiseen:
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ätiedotValppaan asennus- ja käyttöohje
Versio Päiväys Muokkaaja Kuvaus 0.9 16.2.2006 Tuukka Laakso Korjattu versio 0.1 Antti Kettunen Alustava versio Sisällysluettelo 1 Johdanto...2 2 Valppaan asennus...3 2.1 Valppaan kääntäminen...3 2.2 Valmiiksi
LisätiedotProject group Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Staattiset menetelmät Jaakko Nyrölä T-76.115 Software project 2(8) Muutosloki Versio Pvm Tekijä Kuvaus 1.0
LisätiedotOhjelmoinnin jatkokurssi, kurssikoe 28.4.2014
Ohjelmoinnin jatkokurssi, kurssikoe 28.4.2014 Kirjoita jokaiseen palauttamaasi konseptiin kurssin nimi, kokeen päivämäärä, oma nimi ja opiskelijanumero. Vastaa kaikkiin tehtäviin omille konsepteilleen.
LisätiedotOliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä
Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Matti Luukkainen 10.12.2009 Tässä esitetty esimerkki on mukaelma ja lyhennelmä Robert Martinin kirjasta Agile and Iterative Development löytyvästä
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ätiedotSoveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen
Soveltuvuustutkimus Lifebelt-ohjelman ideologian käytettävyydestä olioorientoituneeseen ohjelmointiin Jukka Talvitie Valvoja: Professori Jorma Jormakka Paikka: TietoEnator oyj Ongelma Ideologia Lifebelt
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ä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ä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ätiedotOlio-ohjelmointi Javalla
1 Olio-ohjelmointi Javalla Olio-ohjelmointi Luokka Attribuutit Konstruktori Olion luominen Metodit Olion kopiointi Staattinen attribuutti ja metodi Yksinkertainen ohjelmaluokka Ohjelmaluokka 1 Olio-ohjelmointi
LisätiedotSisällys. Yleistä attribuuteista. Näkyvyys luokan sisällä. Tiedonkätkentä. Aksessorit. 4.2
4. Attribuutit 4.1 Sisällys Yleistä attribuuteista. Näkyvyys luokan sisällä. Tiedonkätkentä. Aksessorit. 4.2 Yleistä Luokan lohkossa, mutta metodien ulkopuolella esiteltyjä muuttujia ja vakioita. Esittely
LisätiedotUutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3
Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2
LisätiedotGood Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi
Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006-11-25 Janne Mäkelä Alustava 1.0 2006-12-10 Janne Mäkelä Valmis 1.
LisätiedotBlueJ ohjelman pitäisi löytyä Development valikon alta mikroluokkien koneista. Muissa koneissa BlueJ voi löytyä esim. omana ikonina työpöydältä
Pekka Ryhänen & Erkki Pesonen 2002 BlueJ:n käyttö Nämä ohjeet on tarkoitettu tkt-laitoksen mikroluokan koneilla tapahtuvaa käyttöä varten. Samat asiat pätevät myös muissa luokissa ja kotikäytössä, joskin
LisätiedotWebforum. Version 17.3 uudet ominaisuudet. Päivitetty:
Webforum Version 17.3 uudet ominaisuudet Päivitetty: 2017-09-23 Sisältö Tervetuloa uudistuneeseen Webforumiin!... 3 Yhteenveto... 4 Dokumentit... 5 Autodesk Forge korvaa RasterExin... 5 Laajennettu API...
LisätiedotDigi-tv vastaanottimella toteutetut interaktiiviset sovellukset
Tekninen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Sisällysluettelo 1. Johdanto...4 1.1. Tarkoitus ja kattavuus...4 1.2. Tuote ja ympäristö...4 1.3. Määritelmät,
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ätiedotOhje kehitysympäristöstä. Dokumentti: Ohje kehitysympäristöstä.doc Päiväys: 15.03.2005 Projekti : AgileElephant
AgilElephant Tekijä: Petri Kalsi Omistaja: ElectricSeven Dokumentti:.doc Päiväys: 15.03.2005 Aihe: Sivu 1 of 6 Dokumenttihistoria Muutoshistoria Revision Revision Yhteenveto muutoksista Revision tekijä
LisätiedotT Loppukatselmus
T-76.115 Loppukatselmus REILU 16.3.2005 Agenda Johdanto (5min) Tuotteen esittely (10 min) Käyttötarkoitus Vaatimukset Ohjelmiston rakenne Demosovellus Projektin arviointi (15 min) Iteraatiot Tavoitteiden
LisätiedotOhjelmointitaito (ict1td002, 12 op) Kevät 2008. 1. Java-ohjelmoinnin alkeita. Tietokoneohjelma. Raine Kauppinen raine.kauppinen@haaga-helia.
Ohjelmointitaito (ict1td002, 12 op) Kevät 2008 Raine Kauppinen raine.kauppinen@haaga-helia.fi 1. Java-ohjelmoinnin alkeita Tietokoneohjelma Java-kieli ja Eclipse-ympäristö Java-ohjelma ja ohjelmaluokka
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ätiedotT-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä
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ätiedot11. oppitunti III. Viittaukset. Osa. Mikä on viittaus?
Osa III 11. oppitunti Viittaukset Kahdessa viime luvussa opit käyttämään osoittimia kohteiden käsittelyyn vapaalla muistialueella sekä viittaamaan noihin kohteisiin epäsuorasti. Tässä luvussa käsiteltävät
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ä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ätiedotT SEPA - päiväkirja: Design Patterns. ETL työkalu
T-76.115 SEPA - päiväkirja: Design Patterns ETL työkalu Versio Päivämäärä Tekijä Kuvaus 1.0 25.10.2004 Jani Honkanen PP-vaiheen jälkeinen versio 1,1 26.11.2004 Mika Suvanto I1- vaiheen kokemuksia lisätty
LisätiedotTietokanta.java Luokka tarjoaa välineet tietokannan lukemiseen. Haetuista tiedoista muodostetaan kurssi- ja opetus-olioita.
Arkkitehtuurikuvaus Käytössä olevat java-luokat: Kansio: /WEB_INF/classes/ - käännetyt luokat Kansio: /WEB_INF/src/ - lähdekoodi custom_pojos: Kurssi.java Java-luokka, jonka sisältö vastaa tietokannassa
LisätiedotRajapintakuvaus Liikenneluvat
Rajapintakuvaus Liikenneluvat MUUTOSHISTORIA Versio Päiväys Laatija Muutoksen kuvaus / hyväksyjä 0.1 Tapio Oikarainen Ensimmäinen versio 2(7) Sisällysluettelo 1. Johdanto... 4 1.1. Yleistä... 4 1.2. Rajaus...
LisätiedotOptimePortal ja OptimeEvent versioiden yhteenveto joulukuu
OptimePortal 1.12.2 ja OptimeEvent 1.16.1 versioiden yhteenveto joulukuu 2016 www.helsinki.fi/yliopisto 1 Tilavaraus Tilavarauspyyntöä luotaessa laskutusyksikkö (ns. H-koodi) voidaan nyt valita viimeisessä
LisätiedotSoftware product lines
Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product
LisätiedotTiedonsiirto helposti navetta-automaation ja tuotosseurannan välillä
Tiedonsiirto helposti navetta-automaation ja tuotosseurannan välillä Tiedonsiirto VMS-, Alpro- tai DelProtuotannonohjausjärjestelmästä Ammuohjelmistoon 5/2014 Asennettavat ohjelmat ja versiot VMS-Management
LisätiedotOhjelmoinnin perusteet, syksy 2006
Ohjelmoinnin perusteet, syksy 2006 Esimerkkivastaukset 1. harjoituksiin. Alkuperäiset esimerkkivastaukset laati Jari Suominen. Vastauksia muokkasi Jukka Stenlund. 1. Esitä seuraavan algoritmin tila jokaisen
LisätiedotEnigmail-opas. Asennus. Avainten hallinta. Avainparin luominen
Enigmail-opas Enigmail on Mozilla Thunderbird ja Mozilla Seamonkey -ohjelmille tehty liitännäinen GPG-salausohjelmiston käyttöä varten. Sitä käytetään etenkin Thunderbirdin kanssa sähköpostin salaamiseen
LisätiedotTuomiorekisterin ratkaisuhaun kehittäminen
25.5.2012 Sivu 1 Muutoshistoria Versio Päiväys Tekijä Kuvaus 0.1 15.2.2012 NMu Luonnos korjattujen ratkaisujen tietojen välittämisen muutoksesta 0.2 12.3.2012 NMu Lisätty uusia metatietokenttiä 0.3 25.5.2012
LisätiedotAutomatisoinnilla tehokkuutta mittaamiseen
Automatisoinnilla tehokkuutta mittaamiseen Finesse seminaari 22.3.2000 Päivi Parviainen 1 Miksi automatisoida? Mittaamisen hyödyt ohjelmistokehityksen ajantasainen seuranta ja hallinta tuotteen laadun
LisätiedotArkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14
Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 1.0 19.10.2007 Suanto 0.3 18.10.2007 Matti Eerola 0.2 17.10.2007
LisätiedotRahastosalkun faktorimallin rakentaminen
Teknillinen korkeakoulu Mat 2.177 Operaatiotutkimuksen projektityöseminaari Kevät 2007 Evli Pankki Oyj Väliraportti 28.3.2007 Kristian Nikinmaa Markus Ehrnrooth Matti Ollila Richard Nordström Ville Niskanen
Lisätiedot<e.g. must, essential, conditional>
Käyttötapaukset Kurssin malli käyttötapauksille: Tila < List of users and the other systems that interacts directly with a system>
LisätiedotLaatukäsikirja - mikä se on ja miten sellainen laaditaan?
Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka
LisätiedotYksikkötestaus. Kattava testaus. Moduulitestaus. Ohjelman testaus. yksikkotestaus/ Seija Lahtinen
Yksikkötestaus Kattava testaus Moduulitestaus Ohjelman testaus 1 Kattava testaus Testauksen perimmäinen tarkoitus on LÖYTÄÄ VIRHEITÄ Testaus pitäisi olla täydellinen: - Jokainen pyydetty arvo pitäisi testata
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ätiedot