Projektisuunnitelma. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 <JULKINEN>
|
|
- Urho Mäkelä
- 8 vuotta sitten
- Katselukertoja:
Transkriptio
1 Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 <JULKINEN>
2 Muutoshistoria Versio Pvm Päivittäjä Muutos Johannes Suanto Päivitetty dokumentti projektin lopun mukaiseksi Johannes Suanto Päivitetty dokumentti Iteraatio 2 alun mukaiseksi Johannes Suanto Päivitetty dokumentti Iteraatio 1:n lopun mukaiseksi Johannes Suanto Merkitty dokumentti julkiseksi Johannes Suanto Lisätty uusi riski Johannes Suanto Päivitetty kohtia 6.1 ja Johannes Suanto Päivitetty kohtia 6.1, Johannes Suanto Esitetty Iteraatiodemossa, päivitetty versioksi Johannes Suanto Päivitetty katselmointikommenttien perusteella Johannes Suanto Päivitetty kohta 2-5.4, Johannes Suanto Päivitetty kohtia 6, 6.1 ja 6.2 mentorin ja asiakkaan palautteen pohjalta Johannes Suanto Päivitetty kohtia 2, 3.1 ja Mikko Luukkonen Päivitetty kohtia 3.2, Johannes Suanto Päivitetty layouttia sekä kohtia 1, 2, 6, 6.1, Matti Eerola Pieniä korjauksia ja kappaleen 5 kirjoittelua Johannes Suanto Ensimmäinen versio
3 Sisällysluettelo Sisältö 1. Johdanto Sidosryhmät ja henkilöstö Tavoitteet Projektin tavoitteet Henkilökohtaiset oppimistavoitteet Resurssit ja budjetti Henkilöstön ajan resursointi Materiaalit Budjetti Käytännöt ja työkalut Käytännöt Iteratiivinen kehitys Iteraatioiden suunnittelu Dokumentointi Riskienhallinta Työajan seuraaminen Kommunikointi Iteraatiodemo Vikojen seuraaminen Versionhallinta Ohjelmointistandardit Prosessin kehitys Vaatimustenhallinta Suunnittelu Laadunvarmistussuunnitelma Työkalut Standardit Vaiheistus Aikataulut Projektisuunnittelu (PP-iteraatio) Tavoitteet Tuotokset Tehtävät Riskit Implementaatio
4 6.3.1.Tavoitteet Tuotokset Tehtävät Riskit Implementaatio Tavoitteet Tuotokset Tehtävät Riskit Riskit... 29
5 1. Johdanto Tämän projektin tarkoituksena on toteuttaa "Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan". Projektin tilaaja on Innofactor Oy ja projektin tuottajana toimii Teknillinen Korkeakoulu. 2. Sidosryhmät ja henkilöstö Projekti toteutetaan osana Teknillisen Korkeakoulun tarjoamaa "T and T Software Development Project I and II" kurssia. Projektiryhmän jäsenet ovat kurssin opiskelijoita ja toimivat projektin kaikissa rooleissa. Asiakkaana toimii Innofactor Oy, joka on tilannut kurssilta "Ratkaisun ohjelmistotuotelinjan monikielisyyden hallintaan". Innofactor on nimennyt projektista vastaavan henkilön omassa organisaatiossaan (Mikko Lampi) sekä erillisen yhteyshenkilön (Juha Kauppi) projektia varten. Lisäksi Juha Kauppi toimii asiakkaan teknisenä asiantuntijana, joka tarvittaessa ottaa mukaan myös muita asiakkaan asiantuntijoita. Varsinaiset ohjelmistotuotelinjan loppukäyttäjät ovat myös eräs sidosryhmä, joka kuitenkin tässä tapauksessa sisällytetään Innofactorin toimintaan. Näin toimitaan koska projektiryhmällä ei ole missään vaiheessa suoraa kosketusta loppukäyttäjiin, vaan Innofactorin asiantuntijat edustavat heitä tässä projektissa. Teknillisen Korkeakoulun puolelta kurssihenkilökunta toimii myös yhtenä sidosryhmänä. Eritoten kurssin vastaava Jari Vanhanen sekä projektiryhmän mentorina toimiva Seppo Sahi ovat aktiivisesti mukana projektin etenemisessä. Lisäksi sidosryhmiksi voidaan laskea muut projektiryhmät, koska kurssin aikana vaihdetaan kokemuksia projektiryhmien välillä, sekä Accenturen konsultit, jotka seuraavat projektiryhmien etenemistä laadunvarmistusnäkökulmasta. 1
6 Alla on kuvattu projektin varsinainen organisaatiokaavio. Kuva 1. Organisaatiokaavio Projektiryhmä koostuu seuraavista Teknillisen Korkeakoulun opiskelijoista ja työntekijöistä. Taulukko 1. Projektiryhmän jäsenet Rooli Nimi Sähköposti Puhelin Projektipäällikkö Johannes Suanto Johannes.Suanto[##]tkk.fi Arkkitehti Matti Eerola mveerol2[##]cc.hut.fi Laadunvarmistuspäällikkö Mikko Luukkonen Mikko.Luukkonen[##]tkk.fi Kehittäjä Aleksi Tolvanen atolvane[##]cc.hut.fi Kehittäjä Arto Tolonen arto.tolonen[##]tkk.fi Kehittäjä Eero Klami eklami[##]cc.hut.fi Kehittäjä Lauri Helkkula lhelkkul[##]cc.hut.fi Kehittäjä Otto Miettinen ojmietti[##]cc.hut.fi Projektiryhmän mentor Seppo Sahi seppo.sahi##google.com Projektiryhmän www-sivut löytyvät osoitteesta: 2
7 3. Tavoitteet 3.1.Projektin tavoitteet Projektin tavoitteena on tarkentaa olemassa olevat monikielisyyden hallinnan määritelmät ja suunnitelmat toteuttamista edellyttävälle tasolle. Lisäksi tavoitteena on suunnitella ja toteuttaa ohjelmistokomponentti sekä varmistaa toteutetun komponentin laadukkuus, toiminta osana varioitavaa tuotelinjaa ja dokumentoida se. Toteutettava ohjelmistokomponentti koostuu tietomallista, yleiskäyttöisestä kirjastosta, jota ohjelmistokehittäjät käyttävät ja jota käytetään kielitermien eli monikielisten tekstien esittämiseen käyttöliittymäkerroksella sekä käyttöliittymästä, jolla monikielisyyttä voidaan hallita (tekstien kääntäminen, muokkaaminen jne.). Ohjelmistokomponentin toteutustekniikkoina käytetään.net ja SQL Server 2005:a. Projektin projektisuunnitteluiteraatiossa on tarkoitus tuottaa projektisuunnitelma, alustava aikataulu ja arkkitehtuuri. Tämän iteraation aikana tutustutaan myös asiakkaan toimintaympäristöön, terminologiaan ja käytössä olevaan, projektin kannalta oleelliseen, ohjeistukseen. Iteraatio 1 vaiheessa tuotetaan ohjelmistokomponentin ensimmäinen toimiva ja testattu versio, joka toteuttaa asiakkaan priorisoimat perustoiminnot. Iteraatio 2 vaiheessa ohjelmistokomponentin toimintaa parannetaan ja siihen lisätään mahdollisuuksien mukaan sellaisia asiakkaan toivomia toimintoja joita ei ehditty toteuttaa iteraatio 1:ssä. Toteutettavassa ohjelmistokomponentissa on erityisesti kiinnitettävä huomioita suorituskykyyn, skaalautuvuuteen, helppokäyttöisyyteen ja ylläpidettävyyteen. Asiakkaan kanssa käytyjen keskustelujen aikana tavoitteet priorisoitiin seuraavasti. Taulukko 2: Asiakkaan priorisoidut tavoitteet Nro Kriteeri Hallittavuus: Termistön suuren koon ja vaihtelevan käytön vuoksi hallittavuus on noussut ehdottomaksi tärkeimmäksi kriteeriksi. Suorituskyky ja skaalautuvuus: Suuren ja kasvavan käyttäjämäärän vuoksi on tärkeää että ratkaisu on suorituskykyinen ja kykenee skaalautumaan hyvin myös tulevaisuudessa Käytettävyys: Käyttäjät ovat tällä hetkellä kehittäjiä, projektipäälliköitä tai muita asiantuntijoita, joten käyttöliittymän on ennemmin oltava tehokas kuin käyttäjää ohjaava työkalu. 3
8 Tavoitteiden täyttymiskriteerejä ei ole vielä tarkennettu asiakkaan kanssa. Ne tarkennetaan kun asiakas on priorisoinut funktionaaliset toiminnot, jolloin kriteerit merkitään alla olevaan taulukkoon jokaisen tavoitteen osalta. Taulukko 3. Tavoitteiden täyttymiskriteerit Tavoite 1. Hallittavuus 2. Suorituskyky 3. Skaalautuvuus 4. Käytettävyys Täyttymiskriteeri 3.2. Henkilökohtaiset oppimistavoitteet Kurssin tavoitteisiin kuuluu myös henkilökohtaisten oppimistavoitteiden asettaminen, seuraaminen ja saavuttaminen projektiryhmän kaikille opiskelijajäsenille. Nämä oppimistavoitteet on merkitty projektin alussa alla olevaan taulukkoon ja niiden täyttymistä seurataan projektin aikana. 4
9 Taulukko 4 Henkilökohtaiset oppimistavoitteet Henkilö Johannes Suanto Matti Eerola Mikko Luukkonen Aleksi Tolvanen Oppimistavoitteet - Oppia johtamaan projektia paremmin - Tutustua uusiin prosesseihin ja tekniikoihin ohjelmistokehityksen saralta - Arkkitehtina toimiminen. - Erilaisten laatukäytäntöjen toteuttaminen käytännössä - Vaatimustenmäärittelyn ja laadunvarmistuksen oppiminen teorian ja työkalujen tasolla. - Arkkitehtuurin suunnittelusta toteutukseen etenemisen ymmärtäminen. ASP.NET:iin tutustuminen. - Oppia toimimaan ryhmässä aiheeseen liittyen; ryhmän jäsenille sopivien työtapojen etsiminen, kommunikointi ryhmän jäsenten kanssa paljolti hajautetussa projektissa ("etätyöstä" syntyvät haasteet), vastuualueiden jakautuminen eri jäsenten välillä ja muut suuren ryhmän ja projektin hallintaan liittyvät probleemat. - Kehitysympäristö on jo melko tuttu, joten tekniikoiden oppiminen ei ole niin tärkeällä sijalla. Kuitenkin mielenkiintoista on nähdä joidenkin työkalujen, kuten Wikin ja Bugzillan hyödyllisyys ja käytettävyys tällaisessa projektissa. - Yleisesti kaikki asiat mitä ei teoriakursseilla opi vaan vain ja ainoastaan kantapään kautta. Vaikka olen kehittäjänä, niin nyt on mahdollisuus myös nähdä vähän pintaa syvemmälle eli nähdä myös hieman koodaamisen ulkopuolelle. Töissä kehittäjänä ei oikein ehdi eikä pysty muuta kuin liukuhihnalta koodata asioita mitä pyydetään. Kurssilla pystynee paremmin keskittymään kaikkeen ohjelmiston suunnittelusta ohjelmiston toimitukseen asti. Lisäksi ohjelmiston kunnollinen testaus eri tekniikoita käyttäen. Töissä kun se jää monesti aika vähälle lähinnä ajanpuutteen takia. 5
10 Arto Tolonen Eero Klami Lauri Helkkula Otto Miettinen - Käytettävien teknologioiden (.net, c#, jne.) oppiminen - Käytettävien metodit ja prosessit (TDD, jne.) oppiminen - Koko projektin seuraaminen ja ymmärtäminen alusta loppuun - Käsitys expertti trion hommista - C#/.NET ympäristön oppiminen - Ohjelmistoprojektin koko elinkaaren näkeminen ja osallistuminen alusta toimitukseen asti. - saada opetetusta teoriasta käytännön kokemuksia - saada parempi yleiskuva koko projektin elinkaaresta - Oppia projektissa käytetyt ohjelmointikielet, jotka tulevat minulle melko uusina tuttavuuksina, sille tasolle, että ne voi hyvällä omatunnolla mainita osaavansa. - Oppia toimimaan projektissa, jossa täytyy opetella paljon uutta pystyäkseen toteuttamaan annetut tehtävät - Oppia lisää projektin ohjauspuolestakin - Lisätä kokemusta ohjelmistoarkkitehtuurin suunnittelusta 4. Resurssit ja budjetti Projektille on resursoitu henkilöitä seuraavasti. 1kpl projektipäällikkö (Suanto) 1kpl laadunvarmistuspäällikkö (Luukkonen) 1kpl arkkitehti (Eerola) 5kpl kehittäjiä (Helkkula, Klami, Miettinen, Tolonen, Tolvanen) Projektin työmääräksi on arvioitu 150 tuntia jokaisen henkilön osalta. Tämän lisäksi kurssin vanhaa versiota suorittavat henkilöt (Luukkonen, Eerola, Helkkula) toteuttavat projektiin kuuluvan "Software Engineering Practice Assignment" (SEPA) osion aiheesta "Automated Unit Testing". SEPA osion tekemiseen on laskettu kuluvan noin 40 tuntia / henkilö yli kurssin normaalin 150 tuntia/henkilö arvion. Tämän johdosta SEPAa suorittaville henkilöille on resursoitu kokonaisuudessaan 190 tuntia tämän projektin tekemiseen (150h + 40h). 6
11 4.1.Henkilöstön ajan resursointi Projektin alussa henkilöiden ajankäytölle laaditaan arvio, jota päivitetään jokaisen iteraation jälkeen. Arviointiin lasketaan mukaan kaikki erilliset tehtävät sekä "yleiset tehtävät" kuten kokoukset, uusien asioiden opiskelu, infrastruktuurin ylläpito ja viestinnän seuranta. Alla olevaan taulukkoon on merkitty projektisuunnittelu-iteraation aikana tehdyt arviot henkilöiden ajankäytöstä eri iteraatioiden aikana. Taulukkoa päivitetään jokaisen iteraation alussa. Taulukko 5: Ajankäytön päivitetty arvio, SEPA mukaan lukien Henkilö PP I1 I2 Yhteensä Suanto Luukkonen Eerola Helkkula Klami Miettinen Tolonen Tolvanen Total Materiaalit Projektissa käytetään seuraavia Teknillisen Korkeakoulun MSDN Academic Alliance-lisenssin kautta hankittuja ohjelmistoja: Microsoft Visual Studio Pro 2005 Microsoft Project
12 Teknillisen Korkeakoulun kautta on saatu käyttöön myös seuraavia sovelluksia CVS MediaWiki Bugzilla MagicDraw UML Lisäksi käytetään seuraavia vapaasti satavilla olevia ohjelmistoja Microsoft SQL Server 2005 Management Studio Express NUnit 4.3. Budjetti Projektilla ei ole varsinaista budjettia vaan kaikki projektiryhmän tekemä työ tehdään opintojen puitteissa ja käytetyt materiaalit ovat joko vapaasti saatavilla olevia tai Teknillisen Korkeakoulun kautta hankittuja. Jokaisen iteraation lopuksi tehdään kuitenkin arvio siitä mitä vastaava työ olisi tullut maksamaan kaupallisen toimittajan tekemänä. Hintaperusteena käytetään jonkin suuren suomessa toimivan IT-toimittajan henkilötyöpäivän (htp) hintaa. Projektisuunnittelu-iteraatiossa kulutettiin noin 265 henkilötyötuntia. Kun tämä jaetaan 7,5:llä saadaan tulokseksi 35,3 henkilötyöpäivää. Suurin osa tästä on suunnittelutyötä josta eräs suuri IT-toimittaja veloittaa noin 1000 / htp. Tällöin projektisuunnittelu-iteraation kustannukseksi olisi tullut noin Samalla periaatteella voidaan laskea arvio Iteraatio 1:lle. Iteraatio 1:n 560 tuntia on noin 74,6 htp. Jos oletetaan että suunnittelua (1000 /htp) on noin 30% ja toteutusta (800 /htp) noin 70% saadaan iteraatio 1:n hinnaksi noin Näillä oletuksilla olisi iteraatio 1:n lopussa kulunut jo Tämä ei luonnollisesti vastaa totuutta koska kaupallisen toimijan tehokkuus on, onneksi, eri luokkaa kuin hajautetusti ja itse hankituilla työkaluilla työtä tekevä opsikelijaprojekti. 5. Käytännöt ja työkalut 5.1. Käytännöt Alla kuvataan projektissa käytetyt käytännöt ja työkalut. 8
13 Iteratiivinen kehitys Iteratiivisella kehityksellä tarkoitetaan kehitystä joka tapahtuu syklisesti, jolloin ensimmäisen kierroksen lopputulos toimii seuraavan kierroksen lähtöpisteenä. Jokaisen iteraation alussa pidetään asiakkaan kanssa iteraatiosuunnittelukokous jonka perusteella luodaan iteraatiosuunnitelma. Tässä suunnitelmassa määritellään mitä toimia iteraation aikana tehdään. Näitä toimia voivat olla mm. vaatimusmäärittely, ohjelmiston suunnittelu, ohjelmointi ja testaus. Samalla päätetään mitä toiminnallisuutta iteraation aikana ohjelmistoon toteutetaan. Asiakas pidetään ajan tasalla viikoittaisilla edistymisraporteilla sekä jokaisen iteraation lopussa pidettävällä iteraatiodemolla, jossa esitellään iteraation tuotokset. Lisäksi asiakkaan kanssa pidetään kokouksia tarpeen mukaan Iteraatioiden suunnittelu Jokaisen iteraation alussa pidetään asiakkaan kanssa iteraation suunnittelukokous, missä asiakkaan kanssa päätetään mitä toiminnallisuuksia toteutetaan tämän iteraation aikana. Päätettyjen tehtävien lisäksi sekä asiakas että projektiryhmä keksii todennäköisesti iteraatioiden aikana lisää tehtäviä. Mikäli nämä eivät ole olemassa olevien tehtävien tarkentamista otetaan ne käsittelyyn vasta seuraavan iteraation suunnittelukokouksessa. Iteraation suunnittelukokoukseen vaaditaan valmistautumista. Projektiryhmän on käytävä läpi jäljellä olevat toiminnallisuusvaatimukset / tehtävät ja annettava niille arvio niiden vaatimasta työmäärästä ja vaikuttavuudesta arkkitehtuuriin, jotta asiakas voi huomioida nämä tiedot omassa priorisoinnissaan Dokumentointi, projektin hallintaan sekä asiakkaan kanssa kommunikointiin liittyvät dokumentit ovat projektipäällikön vastuulla. Projektipäällikkö myös kokoaa ja muuttaa pdf muotoon iteraatiodemoon tarvittavat dokumentit yhdessä dokumenteista vastaavien henkilöiden kanssa. Arkkitehti on vastuussa arkkitehtuurikuvauksesta sekä muista suoraan arkkitehtuuriin liittyvistä kuvauksista (esim. use caset). Laadunvarmistuspäällikkö vastaa laadunvarmistusohjeistuksesta, vaatimusmäärittelydokumentista sekä näihin liittyvistä muista kuvauksista. Jokainen kehittäjä on omalta osaltaan vastuussa kirjoittamastaan koodin kommentoinnista sekä mahdollisista käytön- ja käyttöohjeista. Vastuuhenkilön lisäksi dokumenttien laadinnassa käytetään muiden projektiryhmäläisten asiantuntemusta ja aikaa mahdollisuuksien mukaan työtaakan tasaamiseksi ja tiedon levittämiseksi projektiryhmässä. Dokumentit pyritään katselmoimaan projektiryhmän sisällä ja tärkeimmät dokumentit katselmoitutetaan myös asiakkaalla. Pääasiallisena katselmoinnin organisoijana toimii projektipäällikkö. Aikataulujen niin vaatiessa myös muut voivat käynnistää katselmoinnit. Dokumentit luodaan sopivalla toimisto-ohjelmalla (esim. Microsoft Office). Hajautetusti päivitettävien dokumenttien osalta käytetään Google-Docs palvelua, joka mahdollistaa monen käyttäjän samanaikaisetkin 9
14 editoinnit dokumenteille sekä säilyttää dokumenttien revisiohistorian Riskienhallinta Riskit tunnistetaan aluksi ohjelmistoasiantuntijoiden toimesta ja ne kirjataan riskilokiin tämän projektisuunnitelman kohdassa 7. Projektin aikana riskejä kartoitetaan jatkuvasti eri tapaamisissa sekä projektiryhmän jäsenten normaalissa työssä. Kun jokin riski havaitaan siitä ilmoitetaan ohjelmistoasiantuntijoille, ja tarvittaessa koko projektiryhmälle. Projektipäällikkö huolehtii siitä että tunnistetut riskit tulee merkittyä ja päivitettyä projektisuunnitelmaan. Riskejä käsitellään myös osana muita kokouksia, sekä projektiryhmän sisällä että asiakkaan kanssa. Riskien kirjaaminen ja päivittäminen projektisuunnitelmaan tapahtuu myös tällöin projektipäällikön toimesta Työajan seuraaminen Työaika seurataan 0,25 tunnin tarkkuudella, siten että raportointijakso on yksi viikko. Projektipäällikkö ylläpitää tuntitaulukkoa (Excel), johon on kirjattu avoinna olevat tehtävät, niiden arvioidut tuntimäärät, henkilöille suunnitellut tehtävät tunteineen sekä toteutuneet tunnit. Projektiryhmäläiset raportoivat jokaisena maanantaina klo 18 mennessä sähköpostitse projektipäällikölle edellisenä viikkona käyttämänsä tunnit. Raportoinnissa käytetään projektipäällikön luomaa ja ylläpitämää mallipohjaa, josta käy ilmi avoinna olevat tehtävät, joihin on mahdollista käyttää tunteja. Tuntitaulukkoon ja siitä tuntiraportointimallipohjaan, luodaan uusia tehtäviä projektipäällikön toimesta sitä mukaa kun tunnistetaan tarpeita uusille tehtäville. Kaikki projektiryhmäläiset voivat luonnollisesti ehdottaa uusien tehtävien luomista tilanteen niin vaatiessa. Käytetty työaika raportoidaan asiakkaalle viikoittaisessa raportissa sekä jokaisen iteraation lopussa pidettävässä iteraatiodemossa. Projektiryhmäläiset voivat seurata tilannetta projektipäällikön Google Docsissa ylläpitämästä tuntitaulukosta Kommunikointi Projektiryhmällä on käytössään IRC-kanava jonka kautta on mahdollista kysyä ja saada vastauksia ad-hoctapaan. Teknillisen Korkeakoulun tarjoamaan MediaWikiä käytetään projektiryhmän sisäisten ohjeiden (infrastruktuurin yms. asennusohjeet) luomiseen ja ylläpitoon. Järjestelmän avoimuuden vuoksi se ei kuitenkaan sovellu luottamuksellisen tiedon säilyttämiseen. Sähköpostia käytetään normaaliin kommunikaatioon projektiryhmän jäsenten kesken sekä ensisijaisena kommunikaatiokanavana asiakkaaseen päin sekä virallisempien asioiden kuten työaikaraporttien toimittamiseen. Kokousten järjestämisessä käytetään apuvälineenä -palvelua, jonka kautta on mahdollista sopia parhaiten kaikille sopiva aika. Kokouksia pyritään järjestämään tilanteeseen sopivalla kokoonpanolla. Asiakkaan kanssa pyritään pitämään kokouksia tarvittaessa, eritoten iteraatioiden alussa ja lopussa. 10
15 Iteraatiodemo Projektipäällikkö kokoaa iteraatiodemoon tarvittavan dokumentaation ja muuntaa sen pdf-muotoon mahdollisuuksien mukaan. Valmisteleva työ pyritään saattamaan valmiiksi viimeistään demotilaisuutta edeltämänä päivänä. Arkkitehti puolestaan valmistelee ohjelmistojen demot Vikojen seuraaminen Vikojen seurantaan käytetään koulun tarjoamaa Bugzillaa, joka on käyttäjätunnuksen ja salasanan takana. Tarkemmat ohjeistukset käytöstä tulevat laadunvarmistussuunnitelmaan Versionhallinta Versionhallintaan käytetään CVS:ää. Tarkempi kuvaus eri työkaluista löytyy kohdasta 5.3 Työkalut. Koodi tulisi hakea versionhallinnasta aina kun aloittaa työskentelyn ja viedä takaisin työskentelyn päätteeksi. Versionhallinnasta hakeminen ja sinne vieminen voi tapahtua useamminkin ja se olisi hyödyllistä, jos useampi ohjelmoija muokkaa samaa toiminnallisuutta. Versionhallintaan viennin yhteydessä on suositeltavaa kirjoittaa jokin muutoksia kuvaava viesti, joka tallennetaan CVS:ään. Arkkitehti merkitsee (tag) jokaisen kehitysiteraation puolivälissä ja lopussa kaikki versionhallinnan alaiset tiedostot. Versionhallinnan alaisia tiedostoja ovat ohjelmiston ja testien lähdekoodi ja arkkitehtuurityökalujen tuottamat tiedostot Ohjelmointistandardit Koodausstandardina käytetään Innofactor Oy:n ohjelmointistandardeja, jotka ovat pitkälti yleisten C# ohjelmoinnin käytäntöjen mukaisia. Jokainen ryhmän jäsen on saanut kopion Innofactorin ohjelmointiohjeesta, jossa selitetään Innofactorilla käytettäviä ohjelmointikäytäntöjä. Lisäksi ryhmän jäsenillä on kopio ohjelmakoodin kommentointi -ohjeesta Prosessin kehitys Jokaisen projekti-iteraation päätteeksi projektiryhmä kokoontuu miettimään miten iteraatio meni ja miten seuraavassa iteraatiossa tulisi, toimia jotta se menisi paremmin. Näihin kokouksiin pyritään saamaan mukaan myös ryhmän mentor. Muut prosessinkehitystoimet on kuvattu laadunvarmistusohjeistuksessa (ks. kohta 5.2) Vaatimustenhallinta Vaatimustenhallinta on kuvattu laadunvarmistussuunnitelmassa (ks. kohta 5.2) Suunnittelu Arkkitehtuurin suunnittelu on luonnollisesti arkkitehdin vastuulla. Kehittäjät osallistuvat arkkitehtuurin suunnitteluun siltä osin kuin suunnittelusta voi erottaa sopivan kokoisia alueita kehittäjille. Arkkitehtuuria pyritään suunnittelemaan samalla työkalulla kuin millä alemman tason suunnittelu tehdään. Aina se ei kuitenkaan ole mahdollista. 11
16 Alemman tason suunnittelun tehtävät lisätään tehtävälistaan aina kun tarvetta suunnitteluun tulee. Tehtävälistasta suunnittelutehtävät jaetaan eteenpäin normaalin käytännön mukaisesti Laadunvarmistussuunnitelma Laadunvarmistussuunnitelma on eriytetty erilliseksi dokumentikseen Työkalut Ohjelmistokehitysympäristönä käytetään Microsoft Visual Studio 2005 Pro -ohjelmaa. CVS on tuttu kaikille kehittäjille ja he saavat käyttää omavalintaistaan ohjelmistoa CVS:n käyttöön. Kehitysympäristöön on esimerkiksi tarjolla lisäosa, jolla sen saa toimimaan suoraan CVS:n kanssa ( Voi myös käyttää erillistä ohjelmaa kuten WinCVS. Todennäköisesti helpoin vaihtoehto on käyttää WinCVS:ää, jonka voi ladata ilmaiseksi osoitteesta (versio ). Arkkitehtuurin ja alemman tason suunnitteluun käytetään MagicDraw UML -ohjelmistoa. Tietokannan rakenteen suunnittelussa käytetään Microsoftin Visual Studio SQL Management Studio - ohjelmistoista löytyvää tietokantadiagrammi -työkalua Standardit Projektissa käytetään asiakkaan ohjelmointi- ja dokumentointiohjeita. 6.Vaiheistus Projekti on vaiheistettu kolmeen erilliseen vaiheeseen; Projektin suunnittelu, Iteraatio 1 ja Iteraatio 2. Ensimmäiseen Projektin suunnittelu vaiheeseen kuuluu varsinaisen projektisuunnittelun lisäksi mm. projektiin tutustuminen, työtavoista sopiminen ja muu projektiin liittyvä valmistelutyö kuten infrastruktuurin ja työkalujen valinta ja käyttöönotto. Iteraatioiden 1 ja 2 aikana tehdään suurin osa varsinaisesta projektityöstä, eli ohjelmistotuotelinjan monikielisyyden hallinnan ratkaisun toteuttamisesta tilaajalle Aikataulut Projektilla on sekä ulkoisia että sisäisiä virstanpylväitä. Alla on listattu kaikki projektin kannalta tärkeät päivämäärät kuten iteraatioiden päättymiset, sisäiset aikarajat, tapaamiset asiakkaan kanssa jne. Aikataulua täydennetään ja tarkennetaan jatkuvasti. 12
17 Taulukko 6: Aikataulu Päivämäärä Tehtävä Status Ohjelmistoasiantuntijatiimien kokoaminen OK Asiakasinfo, ensimmäinen tapaaminen asiakkaan edustajan kanssa Kaikki kehittäjät rekrytoitu ryhmään OK Asiantuntijatiimin ensimmäinen suunnittelukokous OK OK Vaihe "Projektisuunnittelu" alkaa Luento kurssilla käytettävästä prosessikehyksestä OK Ensimmäinen suunnittelukokous koko ryhmällä. Mentor mukana Ensimmäinen suunnittelukokous asiakkaan kanssa. OK Projektisuunnittelu iteraation suunnitelman deadline; tämän asiakirjan kohtien 6.1 ja 6.2 toimittaminen asiakkaalle ja mentorille Arkkitehtuurin suunnittelukokous OK Arkkitehtuurikokous asiakkaan kanssa OK Päivitetty versio iteraatiosuunnitelmasta, Infrastruktuurin asennuskokous OK OK OK Suunnittelukokous Projektisuunnittelu iteraation dokumenttien palauttaminen, Iteraatiodemo Projektisuunnitteluiteraation Reflection workshop OK OK Vaihe "Implementaatio 1" alkaa OK Asiakkaan priorisointien määrittely puhelinkokouksessa asiakkaan kanssa DataTier komponentin hankkiminen asiakkaalta ja vieminen CVS:än Iteraatio 1-vaiheen iteraatiosuunnitelman deadline (tämän asiakirjan kohdat 6.1, 6.3 sekä laadunvarmistusdokumentti) Ohjelmoinnin suunnittelukokous OK Ohjelmoinnin suunnittelukokous OK Vko Tilannetapaaminen asiakkaan kanssa Iteraatio 1-vaiheen dokumenttien palauttaminen OK OK OK OK OK 13
18 Iteraatiodemo OK Reflection workshop OK Vaihe "Implementaatio 2" alkaa Ohjelmistoryhmän kokous asiakkaan palautteen käsittelemiseksi ja toiminnallisuuksien vaikuttavuuden ja työmäärän arvioimiseksi Toiminnallisuuksien priorisointikokous asiakkaan kanssa OK Iteraatio 2-vaiheen iteraatiosuunnitelman deadline (tämän asiakirjan kohdat 6.1, 6.4 sekä laadunvarmistusdokumentti) Demo asiakkaan ja mentorin kanssa, osoitettava nähtävissä olevaa edistystä Lopullisen version ja testausohjeiden toimittaminen vertaisryhmälle testausta varten Vertaisryhmän projektin testitulosten raportoiminen vertaisryhmälle Dokumenttien palauttaminen Iteraatiodemo OK OK OK OK OK 6.2. Projektisuunnittelu (PP-iteraatio) Projektisuunnittelu-iteraation tarkoituksena on, varsinaisen projektisuunnitelman tekemisen lisäksi, mahdollistaa ryhmän muodostuminen, työprosesseista sopiminen, työkalujen hankkiminen ja muiden varsinaista projektia edeltävien toimien tekeminen Tavoitteet Projektisuunnittelu-iteraation tärkeimmät tavoitteet ovat: n luominen ja saattaminen sellaiselle valmiusasteelle, että sen perusteella on mahdollista ja turvallista aloittaa varsinaisen projektin tekeminen. Tähän kuuluu mm. asiakkaaseen ja tehtävään tutustuminen, karkea aikataulutus ja tehtävien määrittely, käytettävissä olevien resurssien karkea jako sekä prosessien alustava dokumentointi. Toimintakentän ymmärtäminen siten että projektiin osallistuvat ymmärtävät asiakkaan toimintakenttää riittävästi, jotta asiakkaan tarpeet ja käyttämä kieli sekä terminologia ymmärretään oikein alkavaa projektia ajatellen. Vaatimusmäärittely yleisellä tasolla sekä projektin konkreettisten tavoitteiden asettaminen yhdessä asiakkaan kanssa. Tähän kuuluu asiakkaalle tärkeimpien funktionaalisten vaatimusten ja priorisointien selvittäminen. Lisäksi arkkitehtuurisesti tärkeiden käyttötapausten kuvaaminen siten, että ne tarkentavat yllä mainittuja 14
19 vaatimuksia ja tuovat mahdollisesti esiin uusia tavoitteita. Tässä nimenomaisessa projektissa suuri osa tavoitteista on jo määritelty etukäteen asiakkaan luomassa arkkitehtuurikuvauksessa (Diplomityö: J. Kauppi) Toimintatapojen suunnittelu ja jalkautus. Projektisuunnittelu iteraation aikana projektin laadunvarmistusohjeisto luodaan ja siihen kirjataan projektissa käytettävät toimintatavat, kuten ohjelmointi-, dokumentointi- ja testausstandardit. Ohjeistossa määriteltyjen toimintatapojen jalkauttaminen aloitetaan myös projektin tässä vaiheessa ja sitä jatketaan koko projektin ajan Tuotokset Projektisuunnittelu-iteraation tärkeimmät konkreettiset tuotokset esitellään iteraatiodemossa Niihin kuuluvat seuraavat dokumentit:, joskin sen kohdan 5.2 Laadunvarmistussuunnitelma ei vielä tarvitse olla tarkentunut lopulliseen muotoonsa. Vaatimusmäärittelydokumentti sillä tarkkuudella kun se on mahdollista projektin tässä vaiheessa. Edistymisraportti, joka kuvaa projektin edistymistä, siihen liittyviä tehtäviä ja niihin käytettyä aikaa Tehtävät Projektisuunnittelu-iteraatioon kuuluu tässä iteraatiossa alla mainitut tehtävät. Niiden kuormittavuus on arvioitu projektisuunnittelu-iteraation alussa, taulukossa merkityllä tavalla. Tämä tulee tarkentumaan iteraation mittaan. Taulukko 7: Projektisuunnittelu iteraation tehtävät ID Tehtävä Suunnitellut tunnit Projektiin tutustuminen (kaikille pakollinen tehtävä, perus arkkitehtuuridokumenttiin ja tehtävänantoon tutustuminen) 34 n tekeminen 14 Asiakkaan tarpeiden kartoittaminen, vaihe
20 Arkkitehtuurin jalostaminen (annetusta arkkitehtuurista eteenpäin) 13 Laadunvarmistusohjeistukseen tutustuminen (koodaus- ja dokumentointistandardit) 7 Projektin laadunvarmistusohjeiston tarkentaminen (ohjeiden kokoaminen yhteen tätä projektia varten) 8 Laadunvarmistusprosessin jatkuva päivitys 6 Arkkitehtuurin jatkuva päivitys 7 n jatkuva päivitys 8 Projektin hallinnointi (tuntiseuranta, projektin etenemisen seuraaminen ja ohjaus, raportointi asiakkaalle) 14 Lisäksi tulee iteraation lopuksi tehtävät: Iteraatiodemoon valmistautuminen: 12 tuntia Iteraatiodemo tilaisuus: 12 tuntia Lisäksi yleisiin tehtäviin on varattu aikaa seuraavasti: Kokoukset: 66 tuntia Infrastruktuurin perustaminen ja ylläpito: 23 tuntia Uusien asioiden opiskelu: 34 tuntia Viestinnän seuranta: 16 tuntia Projektisuunnittelu-iteraatioon on siis suunniteltu käytettävän 139 tuntia yleisiin tehtäviin sekä 145 tuntia 16
21 varsinaisiin tehtäviin ja iteraatiodemoon. Yhteensä siis 284 tuntia Osa projektilaisista suorittaa kurssin vanhemman version johon kuuluu myös erillinen SEPA (Software Engineering Practice Assignment) osio, aiheena "automated unit testing". Tähän liittyvät tehtävät tullaan myös merkitsemään projektiin kuuluviksi, kunhan tehtävät selkiytyvät siten, että kurssin vanhaa versiota suorittavilla on käytettävissään 40 ylimääräistä tuntia SEPA-tehtävien tekemiseen verrattuna kurssin uudempaa versiota suorittaviin. Tehtävien keskinäinen tärkeysjärjestys ja keskinäinen riippuvuus on tässä vaiheessa vielä suhteellisen alkeellinen. Ensimmäisenä, ja tärkeimpänä tehtävänä, on luonnollisesti (1) Projektiin tutustuminen. Tämän pohjalta voidaan aloittaa tehtävät (2) "n tekeminen", (3) "Asiakkaan tarpeiden kartoittaminen, vaihe 1", (4) "Arkkitehtuurin jalostaminen" ja (5) "Laadunvarmistusohjeistukseen tutustuminen". Näiden tehtävien pohjalta syntyy dokumentaation ensimmäiset versiot, joita aletaan jatkojalostamaan välittömästi tehtävissä (6), (7), (8) ja (9). Alkumetreiltä asti aina loppuun asti kestävä tehtävänä on (10) "Projektin hallinnointi". Lisäksi aikaa kuluu projektin eri vaiheissa "yleisiin" tehtäviin kuten kokouksiin, infrastruktuurin luomiseen ja ylläpitoon, uusien asioiden opiskeluun sekä viestinnän seurantaan Riskit Riskit kuvataan tarkemmin tämän projektisuunnitelman kappaleessa 7. "Riskit". Lyhyenä yhteenvetona voidaan kuitenkin todeta, että suurin osa nyt tunnistetuista riskeistä liittyy asiakkaan tarpeiden riittävän hyvään ymmärtämiseen (ymmärretäänkö mikä on asiakkaalle oikeasti tärkeää), tarpeeksi selkeän arkkitehtuurin tuottamiseen (saadaanko aikaan niin selvä ja realistinen tavoitetilan kuva, että sen pohjalta on mahdollista aloittaa toteutus) tai projektin resurssitilanteen muuttumiseen (henkilöiden sairastuminen, keskeyttäminen jne.). Riskejä pyritään vähentämään asiakkaan kanssa käydyllä avoimella kommunikaatiolla, projektin tavoitteiden selkeällä määrittelyllä yhdessä asiakkaan kanssa sekä projektitiimin motivoitumisen ylläpitämisellä keskinäisin tapaamisin sekä painottamalla projektista saatavia hyötyjä asiakkaalle ja projektiin osallistuville Implementaatio 1 Implementaatio 1 on ensimmäinen varsinainen toteutuskierros jonka aikana toteutetaan ensimmäinen versio asiakkaan toivomasta ohjelmistokomponentista sekä tähän liittyvästä dokumentaatiosta. Implementaatio 1 alkoi viikolla 43 ja päättyy ohjelmistokomponentin ja dokumentaation esittelyyn asiakkaalle iteraatiodemotilaisuudessa Tavoitteet Iteraatio 1:n tarkoituksena on tuottaa ohjelmistokomponentti joka toteuttaa asiakkaan priorisoiman ydintoiminnallisuuden sekä ne käyttötapaukset jotka on priorisoitu mukaan toteutuksen tähän vaiheeseen. Lisäksi tuotetaan ja päivitetään tähän liittyvä dokumentaatio. Iteraatio 1:n alussa tarkennetaankin ohjelmistokomponentin toteutuksessa käytettävä arkkitehtuuri, komponentin ensimmäisen version toteuttama toiminnallisuus ja käyttötapaukset sekä käytettävä laadunvarmistusohjeisto. Tällöin Iteraatio 1:n lopputuloksena on: 17
22 Ohjelmistokomponentti joka toteuttaa asiakkaan toivoman arkkitehtuurin ja ydintoiminnallisuuden sekä asiakkaan priorisoimat käyttötapaukset. Komponentin dokumentointi sekä ohjelmakoodin kommentoinnin että tarvittavan asennus- ja käyttödokumentaation osalta. Testitapaukset joiden avulla ohjelmistokomponentin toimivuus on testattu Laadunvarmistusraportti sekä testilokit jotka kuvaavat mitä laadunvarmistustoimia on käytetty ja miten tehdyt testit toimivat. -, vaatimusmäärittely- ja, arkkitehtuuridokumenttien päivitetyt versiot jotka kuvaavat projektin, arkkitehtuurin ja vaatimusten tilaa kuten ne ymmärretään iteraatio 1:n lopussa. Toteutussuunnitelma- ja käyttötapaukset dokumenttien päivitetyt versiot jotka kuvaavat teknisen toteutussuunnitelman sekä toteutettujen, ja vielä työjonossa olevien, käyttötapausten tilannetta. Lisäksi palautetaan kurssin vanhaa versiota tekevien henkilöiden osalta T : SEPA diaries dokumentit Tuotokset Iteraatio 1:n tarkoituksena on tuottaa ohjelmistokomponentti joka toteuttaa asiakkaan priorisoiman ydintoiminnallisuuden sekä ne käyttötapaukset jotka on priorisoitu mukaan toteutuksen tähän vaiheeseen. Alla olevassa taulukossa on listattu ne tuotokset joiden on tarkoitus valmistua Iteraatio 1:n aikana Taulukko 8: Iteraatio 1:n tuotokset Ohjelmisto Ohjelmistokomponentin ensimmäinen versio Koodin kommentointi Dokumentit Päivitetty projektisuunnitelma Päivitetty vaatimusmäärittely Päivitetty arkkitehtuuri Päivitetty toteutussuunnitelma Päivitetyt käyttötapaukset Testitapaukset Laadunvarmistusraportti ja testilokit Ohjelmistokomponentin dokumentaatio T : SEPA diaries Edistymisraportti (kalvosarja) Taulukossa 9 on listattu Iteraatio 1:n aikana toteutettava ja testattava ydintoiminnallisuus, eli ne toiminnalliset vaatimukset jotka toteutetaan täysin tai osittain iteraatio 1:n aikana syntyvään 18
23 ohjelmistokomponenttiin. Täydellinen lista toiminnallisista ja laadullisista määrittelyistä löytyy Vaatimusmäärittelyt dokumentista sekä sen liitteistä. Taulukko 9: Toteutettava ydintoiminnallisuus ID Vaatimus Toteutetaan Iteraatiossa 1 F1 Kehitettävän komponentin on tuettava uuden tietomallin mukaista käsitekerrosta. Ensimmäisessä iteraatiossa toteutetaan Juha Kaupin diplomityössä esitetty tietorakenne ja siihen liittyvät ominaisuudet F2 F3 F4 Tietokantaratkaisun on tuettava uuden tietomallin mukaista käsitekerrosta. Kehitettävän komponentin pitää mahdollistaa kielitermien muutosten yhdistäminen uusiin käsitteisiin. Metatietoja on pystyttävä lisäämään ja muokkaamaan tunnisteille, käsitteille ja sisällöille ehdotetun metatietorakenteen mukaisesti. Sama kuin F1 Tietorakenne mahdollistaa erilaisten muutosten tekemisen Ainakin tietorakenteissa kaikki metatiedot toteutetaan. Editoriin toteutetaan mahdollisesti vain taulukkoesitys, johon ei tule kaikkia tietoja näkyviin F6 Kielitermien kääntämistä varten on oltava mahdollista kerätä kaikki tiettyyn tuoteinstanssiin, toiminnallisuuteen tai käyttöliittymäsivuun liittyvät kielitermit. Kaikkien hierarkisten tietojen mukaan hakeminen toteutetaan tietomallissa ja editorissa. F8 Kielitermien tunnisteen keksiminen on oltava mahdollista kehittämisvaiheessa Tietorakenne mahdollistaa F9 Kielitermien tunniste ja sen metatiedot lisätään automaattisesti kielitermikantaan vasta siinä vaiheessa, kun tunnistetta käytetään ajonaikana. Jos tunnistetta ei löydy ja ohjelma on tietyssä tilassa, uusi tunniste lisätään F13 Tietokannan on tuettava kielitermien muokkausta ajonaikaisesti useamman käyttäjän toimesta samanaikaisesti. Käytetään tietokantaa 19
24 F14 F16 Uuden tietomallin eheys on oltava mahdollista tarkistaa automaattisesti. Mikäli tuoteinstallaatiokohtaista kantaa ei ole käytössä, tehdään haku yhteiseen kielitermikantaan. Käytetään tietokantaa Toteutetaan logiikka, joka etsii termejä kummastakin kannasta. Jos installatiokohtaista kantaa ei ole, etsii vain jaetusta kannasta F19 Kehitettävän komponentin on tuettava uuden tietomallin mukaisia hakusääntöjä. Tietomalliin toteutetaan myös hierarkian mukaiset hakusäännöt jne. F20 Kielieditorilla on pystyttävä: A) lisäämään B) hakemaan ja C) muokkaaman kielitermejä. F21 Kielieditorilla on kaksi tilaa: A) käyttömoodi, jossa voi vain hakea kielitermejä (ei muutoksia tietomalliin) B) editointimoodi, jossa voi myös muokata ja lisätä kielitermejä Editoriin toteutetaan hakukontrolli ja taulukon esittävä listauskontrolli, jossa voi muokata ja lisäillä rivejä. ks. F20 F23 F23 F31 F35 F36 Kielieditori sisältää kielitermien sisällön kääntämiseen liittyvät kohdat ja kontekstin, tunniste saattaa näkyä riippuen tilanteesta (erikoistapaus). Kielieditorin on tarjottava useamman samaan kontekstiin liittyvän kielitermin muokkaaminen samalla kertaa yhdessä näkymässä. Tarkistettavaksi merkittyjen kielitermien hakeminen ja näyttäminen on oltava mahdollista. Kielieditorissa on pystyttävä määrittelemään mille kielille kielitermejä käännetään. Kielen vaihtamisen tulee onnistua ajonaikaisesti esimerkiksi valikosta valitsemalla. Kieliä tulee käsitellä samanarvoisesti mitä tulee näiden lisäämiseen kielieditorilla oli kyseessä sitten maakohtainen kieli tai ei. Taulukkoon tulee näkyviin kyseiset tiedot ks. F20 Menee melkein samalla vaivalla hakukontrolliin Kielieditoriin tulee konfattavaksi, mitä kieliä siinä voi valita ks F35 20
25 ID Kuvaus Toteutetaan osittain Iteraatiossa 1 F5 Kaikki kielitermit on sijaittava keskitetysti yhdessä paikassa ja kaikkien kielitermien kääntäminen tai muokkaaminen tapahtuu samalla tavalla: 1. Kielieditorin näkökulmasta kielitermit sijaitsevat yhdessä paikassa 2. Kielitermit on tallennettu samaan paikkaan eli tietokantaan. F10 F11 F27 Kielitermin tunnisteelle on oltava mahdollista antaa kehitysvaiheessa oletussisältö. Kielitermin tunniste on voitava lisätä myös nykyisellä tavalla. Käyttöliittymäsivulta on löydyttävä toiminto, jonka avulla voi kaikkia käyttöliittymäsivun kielitermejä: A) muokata B) merkitä tarkistetuiksi C) asettaa metatietoja. Toteutetaan installaatiotasoon asti eli myös paikallinen tietokanta toteutetaan. Arkkitehtuurin pitäisi tukea myös sen alapuolella olevien tietojen tallennusta, mutta niitä tuotehierarkiatasoja ei toteuteta Toteutetaan vain tietorakenteen osalta Editoriin toteutetaan vain taulukkomuoto jossa voi kyllä luoda uuden rivin eli tunnisteen.jos tarkoitetaan nykyisen kaltaista erillistä kohtaa, johon voi suoraan syöttää tunnisteen niin ei toteuteta. Toteutetaan tietorakenteeseen. Editoriin tulee toteutussuunnitelmassa luetellut tiedot Tehtävät Tehtäville on tehty alustava arvio jo heti iteraation alussa. Tätä arviota päivitetään jatkuvasti projektipäällikön tehtäväseurannassa mutta päivitykset tuodaan projektisuunnitelmaan vasta iteraation lopussa. Taulukko 10: I1 iteraation alustava työmääräarvio tehtäville ID Tehtävä Alustava arvio (h) Y Kokoukset 74 Y Infrastruktuurin perustaminen ja ylläpito 16 Y Uusien asioiden opiskelu 32 Y Viestinnän seuranta Projektin hallinnointi (tuntiseuranta, seuraaminen ja ohjaus) n jatkuva päivitys Arkkitehtuurin jatkuva päivitys Laadunvarmistusprosessin jatkuva päivitys Vaatimusmäärittelyn päivitys 8 31 Katselmoinnit 16 21
26 32 SEPA - suunnittelu SEPA - dokumentointi Käyttötapausten määrittely Toteutussuunnitelman tekeminen 8 36 Tietokantakuvaus valmiiksi 8 37 DataTier hankinta ja vienti CVS:ään 2 38 Toteutettavien osien UML malli 8 39 Toteutettavien komponenttien jako 8 40 Iteraatiodemon valmistelu Iteraatiodemo 8 42 Ohjelmointi (puretaan auki iteraation aikana) Testaus (puretaan auki iteraation aikana) Dokumentointi Ajantasainen iteraation työmäärä löytyy tuntiraportointi excelistä Riskit Riskit kuvataan tarkemmin tämän projektisuunnitelman kappaleessa 7. "Riskit". Lyhyenä yhteenvetona voidaan kuitenkin todeta, että suurin osa Iteraation 1 alussa tiedossa olevista riskeistä liittyy asiakkaan tarpeiden riittävän hyvään ymmärtämiseen (ymmärretäänkö mikä on asiakkaalle oikeasti tärkeää, ymmärretäänkö jos asiakkaan toiveita ei ole mahdollista toteuttaa), tarpeeksi selkeän arkkitehtuurin tuottamiseen (saadaanko aikaan niin selvä ja realistinen tavoitetilan kuva, että sen pohjalta on mahdollista toteuttaa toivottu ohjelmistokomponentti) tai projektin resurssitilanteen muuttumiseen (henkilöiden sairastuminen, keskeyttäminen, aikataulun riittäminen jne.). Riskejä pyritään vähentämään asiakkaan kanssa käydyllä avoimella kommunikaatiolla, projektin tavoitteiden selkeällä määrittelyllä yhdessä asiakkaan kanssa sekä projektitiimin motivoitumisen ylläpitämisellä keskinäisin tapaamisin sekä painottamalla projektista saatavia hyötyjä asiakkaalle ja projektiin osallistuville 6.4. Implementaatio 2 Implementaatio 2 on toinen toteutuskierros jonka aikana toteutetaan asiakkaan toivoma ohjelmistokomponentti sekä tähän liittyvä dokumentaatio. Implementaatio 2 alkoi viikolla 2 ja päättyy ohjelmistokomponentin ja dokumentaation esittelyyn asiakkaalle iteraatiodemotilaisuudessa Tavoitteet Iteraatio 2:n tavoitteena on jatkokehittää iteraatio 1:n aikana tuotettua ohjelmistokomponenttia asiakkaan priorisoitujen toiveiden mukaisesti (ks. taulukko 12. alla). Tämä toteutetaan kahdessa vaiheessa. Ensimmäisessä vaiheessa toteutetaan tärkeimmät asiakkaan priorisoimat toiminnallisuudet versioon joka toimitetaan asiakkaalle asiakkaan testausta varten. Toisessa vaiheessa keskitytään ohjelmistokomponentin testaukseen, virheiden korjaukseen sekä refaktorointiin asiakkaan antaman palautteen perusteella. 22
27 Ohjelmistokomoponentin lisäksi tuotetaan ja päivitetään tähän liittyvä dokumentaatio. Iteraatio 2:n lopussa asiakkaalle luovutetaan testattu ja dokumentoitu versio ohjelmistokomponentista. Iteraatio 2:n lopputuloksena on siis: Ohjelmistokomponentti joka toteuttaa asiakkaan priorisoimat toiminnallisuudet. Komponentin dokumentointi sekä ohjelmakoodin kommentoinnin että tarvittavan asennus- ja käyttödokumentaation osalta. Testitapaukset joiden avulla ohjelmistokomponentin toimivuus on testattu Laadunvarmistusraportti sekä testilokit jotka kuvaavat mitä laadunvarmistustoimia on käytetty ja miten tehdyt testit toimivat. -, vaatimusmäärittely- ja, arkkitehtuuridokumenttien päivitetyt versiot jotka kuvaavat projektin, arkkitehtuurin ja vaatimusten tilaa kuten ne ymmärretään iteraatio 1:n lopussa. Toteutussuunnitelma- ja käyttötapaukset dokumenttien päivitetyt versiot jotka kuvaavat teknisen toteutussuunnitelman sekä toteutettujen, ja jatkokehitykseksi jäävien, toiminnallisuuksien tilannetta. Lisäksi palautetaan kurssin vanhaa versiota tekevien henkilöiden osalta T : SEPA diaries dokumentit Tuotokset Iteraatio 2:n tarkoituksena on tuottaa ohjelmistokomponentti joka toteuttaa asiakkaan priorisoimat ominaisuudet (Hallittavuus, suorituskyky ja skaalautuvuus, käytettävyys ) ja toiminnallisuudet (ks taulukko 12, alla). Taulukko 11: Iteraation 2 tuotokset Ohjelmisto Ohjelmistokomponentin lopullinen versio Ohjelmistokoodi Koodin kommentointi Dokumentit Lopullinen projektisuunnitelma Lopullinen vaatimusmäärittely Lopullinen laadunvarmistussuunnitelma Päivitetty arkkitehtuuri Päivitetty toteutussuunnitelma Päivitetyt käyttötapaukset Testitapaukset Laadunvarmistusraportti ja testilokit Ohjelmistokomponentin dokumentaatio Asennus ja käyttöohjeet T : SEPA diaries Loppuraportti (kalvosarja) 23
28 Taulukossa 12, alla, on kuvattu asiakkaan kanssa priorisoidut toiminnallisuudet jotka toteutetaan mahdollisuuksien mukaan ohjelmistokomponentin lopulliseen versioon. Täydellinen lista aktiivisista, valmiista ja hylätyistä toiminnallisuuksista löytyy "vaatimusmäärittelyt" dokumentista sekä sen liitteestä. Taulukko 12: Iteraatio 2:n priorisoidut toiminnallisuudet nro ID Selite 1 U16 käyttöliittymäsivun osoite (loppuosa) on tultava automaattisen eristämisen yhteydessä kun vieraillaan sivulla 2 U5 policy 2: haetaan käyttöliittymäsivu kerrallaan muistiin (selkein) 3 U9 Tietokannan indeksoinnin optimointi suorituskykyä ajatellen (käytetty policy vaikuttaa indeksointiin) - käyttöliittymäsivu 4 editorin kautta lisättäessä maakohtainen kielitermi se lisätään myös kyseiselle kielelle U12 jos siellä ei jo ole sitä 5 U1 installaatiokohtaisen editoinnin mahdollistaminen (tarve tiputtaa osa välimuistista pois kun muokataan) 6 U2 indeksi joka kertoo mitä tietoja on jo cachessä --> ei tarvetta hakea kannasta, haut käyttävät tätä 7 tarkistusmerkintä voidaan purkaa kielikohtaisesti, asetetaan kuitenkin päälle U13 termikohtaisesti 8 F27 Käyttöliittymäsivulta on löydyttävä toiminto, jonka avulla voi kaikkia käyttöliittymäsivun kielitermejä: A) muokata B) merkitä tarkistetuiksi C) asettaa metatietoja. 9 F29 Kielitermien hakeminen ja muokkaaminen tietyn tuotehierarkiatason, toiminnallisuuden, käyttöliittymäsivun, päiväyksen ja/tai version perusteella. 10 F3 Kehitettävän komponentin pitää mahdollistaa kielitermien muutosten yhdistäminen uusiin käsitteisiin. 11 U21 taulukkoeditorin jakaminen usealle sivulle kun hakutuloksia on paljon 12 U18 oletussisällön liittäminen johonkin kieleen, riittää jos editorissa näkyy oletussisältö suomen kohdalla 13 U20 alasvetovalikot editorissa contextille 14 U25 15 F30 16 F6 "Merkitse kaikki tarkistetuiksi" ja jokaisen rivin perässä myös, jos haluaa vain yksittäisen rivin merkitä tarkistetuksi Kielitermien haku ja muokkaaminen voidaan tehdä tuotehierarkiatason tai ominaisuushierarkian tason yläpuolelle, täsmälleen samalle tasolle tai alapuolelle kuuluville kielitermeille. Kieliä tulee käsitellä samanarvoisesti mitä tulee näiden lisäämiseen kielieditorilla oli kyseessä sitten maakohtainen kieli tai ei. Menee melkein samalla vaivalla hakukontrolliin Kielitermien kääntämistä varten on oltava mahdollista kerätä kaikki tiettyyn tuoteinstanssiin, toiminnallisuuteen tai käyttöliittymäsivuun liittyvät kielitermit. 24
29 17 U11 18 F16 uudelle tunnisteelle on löydettävä olemassaolevaa sisältöä vastaava käsite, käyttäjän nykyisessä kontekstissa, MATTI tarkentaa Mikäli tuoteinstallaatiokohtaista kantaa ei ole käytössä, tehdään haku yhteiseen kielitermikantaan. 19 U6 policy 3: haetaan toiminnallisuus kerrallaan muistiin 20 U10 Tietokannan indeksoinnin optimointi suorituskykyä ajatellen (käytetty policy vaikuttaa indeksointiin) - toiminnallisuus 21 U4 policy 1: haetaan kaikki contentit heti kerralla muistiin 22 logiikka: voitava muokata metatietoja muokkauksen yhteydessä, esim mihin versioon U15 kuuluu 23 tuotantomoodissa näytetään oletussisältö, kehitysmoodissa "content not found" jos U22 tyhjä, muuten kans oletus 24 U23 tarkistettavat termit erottuvat hyvin käyttöliittymästä 25 U24 26 F32 Käyttöliittymäsivun alalaitaan lista kaikista sivulla olevista kielitermeistä, nappi joka vie editoriin riittää Kielitermit on voitava merkitä tarkistettavaksi halutulle tuotehierarkiatasolle ja kielelle. (liittyy ylempänä olevaan tarkistuslistaan käyttöliittymäsivukohtaisesti) 27 F22 Kielieditorin on tuettava kielitermien poistamismahdollisuutta? 28 U17 käyttöliittymäsivun selkokielinen nimi näkyviin --> millä kielellä --> oletuskieli 29 U19 käyttöliittymän nopeus (repeater control jne tms nopeutustoimia) 30 U14 tunnisteiden poistaminen (automaattinen tarkistus onko sivulla poistettavia tunnisteita) 31 U3 cache leveleiden lisääminen (muistin lisäksi esim levyvälimuisti) 32 F25 33 F17 Kielieditorilla pitää pystyä luomaan lista tuoteinstanssissa käytössä olevista kielitermeistä. Käyttäjäkohtaiset termit haetaan istunnon aloittamisen jälkeen istuntokohtaiseen muistiin (vain sen käyttäjän kielitermit, jolle istunto kuuluu). 34 U8 logiikka: mikä on paras policy toimia tämän sivun kohdalla 35 F38 Dynaamisilla kielitermeillä on monikkomuodot eri kielille 36 F37 Dynaamisilla kielitermeillä on erilaiset kontekstiriippuvaiset esitysmuodot. Toteutetaan metodi, jolla haetaan perustapauksien (numero, päivämäärä, valuutta) esitysmuodot ainakin kielen perusteella, mahdollisesti myös tuotehierarkian perusteella Tehtävät Tehtäville on tehty alustava arvio jo heti iteraation alussa. Tätä arviota päivitetään jatkuvasti projektipäällikön tehtäväseurannassa mutta päivitykset tuodaan projektisuunnitelmaan vasta iteraation lopussa. Harmaalla merkityt tehtävät ovat asiakkaan alemmalle prioriteetille asettamia ja ne karsitaan ensin pois jos aikapulaa ilmenee. 25
30 Taulukko 13: I1 iteraation alustava työmääräarvio tehtäville ID Nimi tunteja Y Kokoukset 40 Y Infrastruktuurin perustaminen ja ylläpito 6 Y Uusien asioiden opiskelu 14 Y Viestinnän seuranta Projektin hallinnointi (tuntiseuranta, seuraaminen ja ohjaus) n jatkuva päivitys 4 53 Arkkitehtuurin jatkuva päivitys 4 54 Laadunvarmistusprosessin jatkuva päivitys 8 55 Vaatimusmäärittelyn päivitys 4 56 Katselmoinnit SEPA - suunnittelu SEPA - dokumentointi U 16: käyttöliittymäsivun osoite (loppuosa) on tultava automaattisen eristämisen yhteydessä kun vieraillaan sivulla U5: policy 2: haetaan käyttöliittymäsivu kerrallaan muistiin (selkein) U9: Tietokannan indeksoinnin optimointi suorituskykyä ajatellen (käytetty policy vaikuttaa indeksointiin) - käyttöliittymäsivu U12: editorin kautta lisättäessä maakohtainen kielitermi se lisätään myös kyseiselle kielelle jos siellä ei jo ole sitä U1: installaatiokohtaisen editoinnin mahdollistaminen (tarve tiputtaa osa välimuistista pois kun muokataan) U2 indeksi joka kertoo mitä tietoja on jo cachessä --> ei tarvetta hakea kannasta, haut käyttävät tätä U13: tarkistusmerkintä voidaan purkaa kielikohtaisesti, asetetaan kuitenkin päälle termikohtaisesti
Projektisuunnitelma. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14
Projektisuunnitelma Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 1.0 19.10.2007 Johannes Suanto Esitetty Iteraatiodemossa,
LisätiedotProjektisuunnitelma. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 <JULKINEN>
Projektisuunnitelma Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 2.0 5.12.2007 Johannes Suanto Päivitetty dokumentti
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 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2
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ätiedotLoppuraportti. Ryhmä 14. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan. Innofactor Oy
Loppuraportti Ryhmä 14 Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Version Date Author Description 0.1 29.2.2008 Suanto Ensimmäinen versio Sisällysluettelo T-76.4115 / T76.5115
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ä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ätiedotS11-09 Control System for an. Autonomous Household Robot Platform
S11-09 Control System for an Autonomous Household Robot Platform Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Quang Doan Lauri T. Mäkelä 1 Kuvaus Projektin tavoitteena on
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ä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ä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ätiedotLego Mindstorms anturit
Lego Mindstorms anturit Metropolia Ammattikorkeakoulu Projektisuunnitelma Tomi Ilonen KA09 Tommi Nuotiomaa KA09 Matias Pitkänen KA09 20.1.2012 Insinöörityö Päivämäärä Sisällys 1 Projektin kuvaus 1 1.1
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ätiedotOpetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen
Opetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen Toiminnallinen määrittely: Työsuunnitelma TYÖSUUNNITELMAN TIEDOT Versio 0.1 Laatija Ulla Angervo Laatimispäivämäärä Hyväksyjä Hyväksymispäivämäärä
LisätiedotIT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS
20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien
LisätiedotSALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti
Järjestelmäprojekti 1 projektisuunnitelma ICT4TN007-2 SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti Versio 0.1 Tekijät Keijo Nykänen Tarkastanut Hyväksynyt HAAGA-HELIA
LisätiedotToiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen
Vaatimusluettelo versio 0.17 Toiminnalliset ja ei-toiminnalliset vaatimukset Tunnus (ID) Vaatimus Vaatimuksen Yleiset vaatimukset 1 Koodistopalvelujärjestelmä on selainkäyttöinen 2 Käyttöliittymän tulee
LisätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu KÄYTTÖOHJE. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu JÄRJESTELMÄN KÄYTTÖOHJE LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001
LisätiedotSisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä
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ätiedotData Sailors - COTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................... 1 1.1 Versiohistoria...........................................................................
LisätiedotSisäänrakennettu tietosuoja ja ohjelmistokehitys
Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology
LisätiedotToteutusvaihe T2 Edistymisraportti
Toteutusvaihe T2 Edistymisraportti Sisällysluettelo 1. Projektin tila...3 1.1. Suoritetut tehtävät...4 1.2. Käytetyt menetelmät...5 1.3. Ongelmat...6 1.4. Jatkosuunnitelmat...6 Versio- ja muutoshistoria
LisätiedotKuopio Testausraportti Asiakkaat-osakokonaisuus
Kuopio Testausraportti Asiakkaat-osakokonaisuus Kuopio, testausraportti, 25.3.2002 Versiohistoria: Versio Pvm Laatija Muutokset 0.1 11.2.2002 Matti Peltomäki Ensimmäinen versio 0.9 11.2.2002 Matti Peltomäki
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ä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ätiedotTestaussuunnitelma Labra
Testaussuunnitelma Labra Helsinki 25.8.2008 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 1 Kurssi 581260 Ohjelmistotuotantoprojekti (9+1op) Projektiryhmä Anssi Kapanen,
LisätiedotFENG OFFICE -PROJEKTINHALLINTATYÖKALU
1(5) FENG OFFICE -PROJEKTINHALLINTATYÖKALU Verkkoprojektissa tarkoituksenmukaisen projektinhallintatyökalun käyttö vähentää viestintään kuluvaa työaikaa merkittävästi, kun projektin osapuolilla on reaaliaikainen
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ä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ätiedotTämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:
Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus
LisätiedotJHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi
JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Katselmointi osana laadunvarmistusta... 2 2 Yleistä katselmoinneista...
LisätiedotTIETOJENKÄSITTELYTIETEIDEN LAITOS
TIETOJENKÄSITTELYTIETEIDEN LAITOS PROJEKTITOIMINNAN PERUSTEET TENTTI 28.4.2001 Tonja Molin-Juustila Kustakin tehtävästä max 6 pistettä. Vastaukset arvostellaan 0,5 pisteen tarkkuudella. Oikeat vastaukset
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ätiedotReilun Pelin työkalupakki: Kiireen vähentäminen
Reilun Pelin työkalupakki: Kiireen vähentäminen Tavoitteet Tämän toimintamallin avulla opit määrittelemään kiireen. Työyhteisösi oppii tunnistamaan toistuvan, kuormittavan kiireen sekä etsimään sen syitä
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ätiedotProjektiryhmä Tete Työajanseurantajärjestelmä. Käyttöohje
Projektiryhmä Tete Työajanseurantajärjestelmä T-76.115 Tietojenkäsittelyopin ohjelmatyö 2(14) Muutoshistoria Version Date Author Description 0.10 1.12.2003 Miikka Lötjönen First incomplete draft 0.20 6.2.2004
LisätiedotInternet-pohjainen ryhmätyöympäristö
Menetelmäohje Internet-pohjainen ryhmätyöympäristö Riku Hurmalainen, 24.3.2002 Sisällysluettelo 1. Johdanto...3 2. Termit...4 3. Toteutus...5 3.1. Yleiskuvaus...5 3.2. Tekninen ratkaisu...5 3.3. Tietoturva...6
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ätiedotAS Automaatio- ja systeemitekniikan projektityöt - Projektisuunnitelma
AS-0.3200 Automaatio- ja systeemitekniikan projektityöt - Projektisuunnitelma PiccSIM - TrueTime integrointi Henri Öhman 31.1.2012 1. Projektityön tavoite PiccSIM on Aalto-yliopistolla kehitetty simulointiympäristö,
LisätiedotKansallinen ASPAtietojärjestelmä
Kansallinen ASPAtietojärjestelmä Taustoitus Järjestäjien tarve yhteiselle asiakaspalautteen keräämisen järjestelmälle nousi esiin kevään selvityksessä Asiakaspalautetieto on myös osa kansallista sote-tietopohjaa
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ätiedotHarjoitustyö Case - HelpDesk
Harjoitustyö Case - HelpDesk Harjoitustyön Case: HelpDesk -sovellus Tietotekniikkatoimittaja AB ja asiakas X ovat viime vuonna sopineet mikrotukiyksikön ulkoistamisesta X:ltä AB:n liikkeenjohdon vastuulle.
LisätiedotTARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa
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ätiedotMäärittelyvaihe. Projektinhallinta
Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti
LisätiedotOhjelmisto on selainpohjaisen käyttöliittymän tarjoava tietokantajärjestelmä merikotkien seurantaan WWF:n Merikotka-työryhmän tarpeisiin.
TIETOKANTA MERIKOTKIEN SEURANTAAN Käyttöohje Versiohistoria: Versio Päivämäärä Kuvaus Tekijä 1.0 11.12.2007 Ensimmäinen luonnos Janne Piippo 2.0 13.12.2007 Virallinen verio Janne Piippo HELSINGIN YLIOPISTO
LisätiedotKieliversiointityökalu Java-ohjelmistoon. Ohje
Kieliversiointityökalu Java-ohjelmistoon Ohje 2/6 SISÄLLYSLUETTELO 1 YLEISTÄ OHJELMASTA... 3 2 PÄÄ-IKKUNA...4 3 YLÄVALIKKO... 4 3.1 TIEDOSTO... 4 3.2 TOIMINTO... 4 3.3 ASETUKSET... 5 3.4 OHJE... 5 4 VÄLILEHDET...5
LisätiedotSopimus Asiakas- ja potilastietojärjestelmästä. Liite N: Kielivaatimukset
Sopimus Asiakas- ja potilastietojärjestelmästä Liite N: Kielivaatimukset VERSIOHISTORIA Päivä Versio Kuvaus Tekijä 12.3.15 3.0 Tarjouspyynnön liitteeksi 2 (6) SISÄLLYSLUETTELO 1 JOHDANTO... 4 2 JÄRJESTELMÄN
LisätiedotLOPPURAPORTTI Paperikonekilta Versio 1.0
Loppuraportti LITA/TIKO/PAPERIKONEKILTA 1 (14) 18.5.2009 LOPPURAPORTTI Paperikonekilta Versio 1.0 Tekijät: Jaakko Karhunen Jani Hyvönen TIKO, IT-Dynamo 5.kerros Osoite: Tietojenkäsittelyn koulutusohjelma
LisätiedotOppilaan pikaopas. Project 2013 käyttöliittymä ja näkymät
1 Oppilaan pikaopas Project 2013 käyttöliittymä ja näkymät Kun avaat Project 2013 -ohjelman, näet ensimmäisenä pelkistetyn näkymän. Uusi Project 2013 voi auttaa projektinhallinnassa kuten esim. projektitietojen
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ä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ä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ä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ä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ätiedot1. ASIAKKAAN OHJEET... 2. 1.1 Varauksen tekeminen... 2. 1.2 Käyttäjätunnuksen luominen... 4. 1.3 Varauksen peruminen... 4
1. ASIAKKAAN OHJEET... 2 1.1 Varauksen tekeminen... 2 1.2 Käyttäjätunnuksen luominen... 4 1.3 Varauksen peruminen... 4 1.4 Omien tietojen muokkaaminen... 5 1.5 Salasanan muuttaminen... 5 2. TYÖNTEKIJÄN
LisätiedotKäyttöohje. Versiohistoria: 1.0 7.5.2003 1. versio Mari 1.1 9.5.2003 Kommenttien perusteella korjattu versio
Otus- projektinhallintatyökalu Käyttöohje Versiohistoria: 1.0 7.5.2003 1. versio Mari 1.1 9.5.2003 Kommenttien perusteella korjattu versio Mari Tampere 9. toukokuuta 2003 Kimmo Airamaa, Andreas Asuja,
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ä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ätiedotAS-0.3200 Automaatio- ja systeemitekniikan projektityöt
AS-0.3200 Automaatio- ja systeemitekniikan projektityöt A11-17 Ikäihmisten kotona asumista tukevien järjestelmien kehittäminen AikatauluValpas Salla Ojala Paula Laitio 1. Projektin tavoite Projektimme
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ä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ätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite
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ätiedotPS-vaiheen edistymisraportti Kuopio
PS-vaiheen edistymisraportti Kuopio Kuopio, PS-vaiheen edistymisraportti, 30.10.2001 Versiohistoria: Versio Pvm Laatija Muutokset 1.0 30.10.2001 Ossi Jokinen Kuopio2001, vain kurssin T-76.115 arvostelun
LisätiedotWebforum. Version 17.2 uudet ominaisuudet. Päivitetty:
Webforum Version 17.2 uudet ominaisuudet Päivitetty: 2017-06-17 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Dokumentit... 5 Luo uusia Microsoft Office dokumentteja työkaluriviltä... 5 Uusi edistymispalkki
LisätiedotHallintaliittymän käyttöohje
Hallintaliittymän käyttöohje 1. Yleisiä huomioita Hallintaliittymän käyttöä helpottavia yleisiä huomioita: - Käytä listanäkymien hakukentissä kentän vieressä olevaa hakunappia, älä enter-näppäintä. - Älä
LisätiedotValtioneuvoston kanslia VAIN VIRKAKÄYTTÖÖN Hallinto- ja palveluosasto/hallintoyksikkö Terja Ketola PTJ2008-työsuunnitelma 1 (5)
Terja Ketola PTJ2008-työsuunnitelma 1 (5) AIKATAULU JA TEHTÄVÄT / PTJ2008 VALMIS MENOSSA MYÖHÄSSÄ ALOITTAMATTA ALUSTAVA AJANKOHTA EI PIDETTY / TEHTY 1 Määrittelyn läpikäynti PTi, TKe, IHa, TRö 34 23.8.2007
LisätiedotKieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä
Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä Omistaja Tyyppi Tiedoston nimi Turvaluokitus Kohderyhmä Turvaluokituskäytäntö --- SE/Pekka Järveläinen Projektisuunnitelma projektisuunnitelma_kielihallinto.doc
LisätiedotProjektin suunnittelu
Projektin suunnittelu Sami Kollanus TJTA330 Ohjelmistotuotanto 15.3. Projektin suunnittelu - CMMIkäytänteet Projektin estimaatit: Määritellään projektin laajuus (scope) Määritellään tehtävien ja tuotosten
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ä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ätiedotCOTOOL dokumentaatio Riskiloki
Table of Contents 1 Johdanto.................................................................................. 1 1.1 Versiohistoria...........................................................................
LisätiedotSALITE.fi -Verkon pääkäyttäjän ohje
SALITE.fi -Verkon pääkäyttäjän ohje Sisältö 1 Verkon pääkäyttäjä (Network Admin)...3 2 Verkonhallinta...3 2.1 Navigointi verkonhallintaan...3 2.2 Sivustot...3 2.1 Sivustojen toiminnot...4 2.3 Sivuston
LisätiedotADMIN. Käyttöopas 08Q4
ADMIN Käyttöopas 08Q4 Sisällysluettelo Uuden käyttäjän lisääminen...3 Käyttäjän poistaminen...3 Oikeudet...4 Käyttäjäasetukset...6 Aktiviteetin määritys...8 Aktiviteetin määrittely...8 Kenttämäärittelyt...9
LisätiedotNEPTON JÄSENTIETO - PERUSVERSIO käyttöohjeet lyhyesti
Suomen Voimisteluliitto NEPTON JÄSENTIETO - PERUSVERSIO käyttöohjeet lyhyesti Nepton perusversio on seuran yhteyshenkilörekisteri ja jäsenrekisteri. Perusversiota käyttää seurassa henkilö/t, jolle on annettu
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ätiedotPROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS
PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS 10 KEYS TO SUCCESSFUL SOFTWARE PROJECT 1. Clear Vision 2. Stable, Complete, Written Requirements 3. Detailed User Interface Prototypes
LisätiedotLarppa-laskutusohjelma v1.1 Ohje
Larppa-laskutusohjelma v1.1 Ohje Larppa-laskutusohjelma Larppa-laskutusohjelma on tarkoitettu pienen yrityksen laskujen tulostamiseen ja arkistointiin. Ohjelma tarvitsee Microsoft Excel ohjelman toimiakseen
LisätiedotWebforum. Version 14.4 uudet ominaisuudet. Viimeisin päivitys: 2014-12-6
Webforum Version 14.4 uudet ominaisuudet Viimeisin päivitys: 2014-12-6 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Yleistä & hallinnointi... 5 Dokumentit... 5 Perättäinen tarkistus- ja hyväksymisprosessi...
LisätiedotUuden työ- tai mittavälineen luominen tietokantaan
Sivu:1(12) Työ- ja mittaväline-tietokanta löytyy serveriltä APPL14.DE.ABB.COM/SRV/ABB Tarvitset read-oikeudet tietokannan tarkasteluun ja editor mainusers-oikeudet tietokannan muokkaukseen. Jos tarkoituksenasi
LisätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
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ä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ätiedotLoppuraporttiohjeistus Innovaation siirto -hankkeille
Loppuraporttiohjeistus Innovaation siirto -hankkeille Päivitetty 13.3.2015 Yleistä sisällön raportoinnista Jokainen hanke toimittaa vain yhden väli- ja loppuraportin. Koordinaattori on vastuussa tietojen
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ä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ä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ätiedotTietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto
LisätiedotGoogle-työkalut: Dokumenttien jakaminen ja kommentointi
Google-työkalut: Dokumenttien jakaminen ja kommentointi Dokumenttien jakaminen Google työkaluilla luodut dokumentit on jaettavissa muille käyttäjille Jaa painikkeella, joka sijaitsee työkalujen oikeassa
LisätiedotKÄYTTÖOHJE. Servia. S solutions
KÄYTTÖOHJE Servia S solutions Versio 1.0 Servia S solutions Servia Finland Oy PL 1188 (Microkatu 1) 70211 KUOPIO puh. (017) 441 2780 info@servia.fi www.servia.fi 2001 2004 Servia Finland Oy. Kaikki oikeudet
LisätiedotOhjelmistotuotteen hallinnasta
Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista
LisätiedotProjektinhallinta SFS-ISO mukaan
Projektinhallinta SFS-ISO 21500 mukaan (Ohjeita projektinhallinnasta, 2012) 13.4.2017 Panu Kiviluoma Osaamistavoitteet Luennon jälkeen osaat selittää, mitä tarkoitetaan Projektilla Projektinhallinnalla
LisätiedotMäärittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli
LisätiedotProvet Net Kutsut ohje
Provet Net Kutsut ohje Provetissa voidaan kutsuja käyttää pitkä-aikaisten asiakassuhteiden ylläpitoon. Kutsujen avulla asiakkaita voidaan muistuttaa lemmikin rokotusten voimassa olosta, hampaiden säännöllisestä
LisätiedotPower Steering for ATV
AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Power Steering for ATV 27.1.2014 Juuso Meriläinen Antti Alakiikonen Aleksi Vulli Meriläinen, Vulli, Alakiikonen 1/6 Projektin tavoite Projektityössä
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 14.3 uudet ominaisuudet. Viimeisin päivitys: 2014-09-14
Webforum Version 14.3 uudet ominaisuudet Viimeisin päivitys: 2014-09-14 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Yleistä & hallinnointi... 5 Käyttäjien tuonti toiselta alustalta... 5 Uusi sisäänkirjautumisen
Lisätiedot