Esipuhe Kirjallisuutta:

Koko: px
Aloita esitys sivulta:

Download "Esipuhe Kirjallisuutta:"

Transkriptio

1 Esipuhe Tämä moniste sisältää perustietoa tietojärjestelmistä ja niiden kehittämisestä. Siinä on myös suhteellisen kattava kuvaus tietojärjestelmien tunnetuimmista kehitysmenetelmistä ja niiden perusperiaatteista. Tietojärjestelmien suunnittelua tarkastellaan esimerkkien avulla osana laajempaa organisaation toiminnan suunnittelua. Tavoitteina on selvittää mitä ovat tietojärjestelmät, miksi ne ovat organisaatioille välttämättömiä ja miten niitä sovelletaan erilaisiin ympäristöihin. Monisteessa käsitellään tietojärjestelmien kuvaustekniikkoja ja suunnittelumenetelmiä, erityisesti ER- ja oliomallia. Varsinaisia perustietoja kurssin suorittaminen ei vaadi - tosin alan peruskäsitteiden hallinnasta ja käytännön kokemuksesta on kurssilla hyötyä. Tämä moniste perustuu lähinnä englanninkieliseen lähdemateriaaliin, kuten DeMarcon, Elmasri & Navathen ja Coad & Yourdonin teoksiin sekä moniin aiempiin, enemmän tai vähemmän kyseisten teosten pohjalta laadittuihin monisteisiin, joita ovat vuosien varrella olleet kirjoittelemassa ainakin (aakkosjärjestyksessä) Erkki Innola, Jari Kesti, Mika Kirveennummi, Päivi Saalasto, Jukka Teuhola ja Vesa Torvinen. Kirjallisuutta: Avison, D. & Fitzgerald, G. Information Systems Development: Methodologies, Techniques and Tools, 2nd ed., McGraw-Hill Publishing Company, Coad, P. & Yourdon, E. Object-oriented analysis, Second edition. Yourdon Press, New Jersey, DeMarco, T. Structured Analysis and System Specification. Prentice-Hall Inc., Elmasri, R. & Navathe, S. Fundamentals of Database Systems. Addison-Wesley, Gane, C. & Sarson, T. Structured Systems Analysis: tools and techniques. Prentice- Hall Inc., Kroenke, David & Hatch, Richard: Management Information Systems, 3 edition, McGraw-Hill, USA, Mannila, H. & Räihä, K-J. The Design of Relational Databases. Addison-Wesley, Teuhola, J. Tietokantojen jatkokurssi, Yourdon, E. Modern Structured Analysis. Prentice-Hall,

2 SISÄLLYSLUETTELO 1 JOHDANTO TIETOJÄRJESTELMIIN Tietokoneen historia Tietojärjestelmien historia Tietojärjestelmien kehittäminen 5 2 TIETOJÄRJESTELMIEN KEHITTÄMINEN Lineaarinen elinkaari Tietojärjestelmäprojekti 12 2

3 1 JOHDANTO TIETOJÄRJESTELMIIN 1.1 Tietokoneen historia Tietokone on alun perin kehitetty laskukoneeksi. Tietokoneen englanninkielinen nimi, computer, onkin tarkkaan suomennettuna laskija. Kenties ensimmäinen ihmisen historian varsinainen laskukone on ollut kiinalainen helmitaulu (1300-luku). Muita tietokoneen historiaan liittyviä kuuluisia laskukoneita ovat olleet William Oughtredin vuonna 1622 luoma laskukone (slide rule), jota insinöörit käyttivät aina 1900-luvun alkuun saakka sekä Blaise Pascalin laskukone (1642), jossa oli jo eräänlainen tulostusikkuna sekä näppäimistö. Tietokoneen taustalta löytyy hieman yllättäviäkin keksintöjä. Esimerkiksi ranskalaisen Joseph-Marie Jacquardin keksimä automaattinen kutomakoneen (1801), jossa reikäkortit ohjasivat eri kuvioiden vaihtumista kankaan kudonnassa, noudattaa paljolti samoja periaatteita kuin aikaisimmat tietokoneet. Toisaalta 1800-luvun suuri laivastoihin liittyvä ongelma, navigointi, on aikoinaan johtanut tietokonetta muistuttavan koneen kehittämiseen. Charles Babbage kehitti koneen (1822, Difference Engine), joka auttoi laivojen navigoinnissa ja näin vähensi laskennassa sattuvia virheitä sekä laivoille tapahtuvia onnettomuuksia. Charles Babbagen toinen kone, Analytical Engine, sisälsi jo niin paljon modernin tietokoneen komponentteja, että häntä pidetään yleisesti tietokoneen isänä. Tietokoneen historia ei suinkaan ole pelkkää miesten historiaa. Maailman ensimmäisenä ohjelmoijana pidetään kreivitär Ada Augusta Kingiä. Hän oli amatööri matemaatikko, joka käytti Charles Babbagen Analytical Engineä ohjelmointiin (1842). Seuraava merkittävä tapahtuma tietokoneen historiassa oli USA:n väestönlaskenta vuonna Sitä helpottamaan pidettiin kilpailu, jossa etsittiin tiedon prosessointiin uusia apuvälineitä. Kilpailun voittaja perusti C-T-R -nimisen yhtiön vuonna Yhtiö nimettiin uudelleen vuonna 1924 IBM:ksi. Varsinaisen tietokoneen keksimistä ennen on nähtävissä eri puolilla maailmaa tapahtunut kehittämisen kilpajuoksu. Esimerkiksi saksalainen Konrad Zuse kehitti oman versionsa tietokoneesta vanhempiensa olohuoneeseen ( , Z-1). John Vincent Atanasoff yhdessä John Berryn kanssa kehitti koneen nimeltä ABC ( , Atanasoff-Berry Computer) USA:ssa. Kone on ehkä aikaisin esimerkki elektronisesta laskimesta. Alan Turing kehitti idean koneesta, joka olisi niin yleinen, että sillä voitaisiin ratkaista mitä tahansa, kuvattavissa olevia algoritmeja (1937). Toisen maailmansodan aikaan monet tiedemiehet ympäri Atlanttia työskentelivät salakirjoituksen parissa. Kuuluisin kone, joka tuona aikana syntyi, oli Oxfordin ja Cambridgen yliopistoissa kehitetty Colossus (1943). Mm. Turing oli mukana kehittämässä tätä konetta. Ensimmäinen suuri, automatisoitu, yleisiin ongelmiin tarkoitettu, elektromekaaninen laskin oli Harvard Mark I (1944). Koneen rakentamista sponsoroi USA:n armeija ja se oli tarkoitettu erilaisten matemaattisten taulukoiden, kuten myös navigointiin liittyvien taulukoiden laskentaan. Modernin tietokoneen syntymisvuotena pidetään kuitenkin vuotta 1948, jolloin Englannissa julkaistiin kone 3

4 nimeltä Manchester Mark I (tai Manchester Baby), jossa ensimmäistä kertaa voitiin tallettaa ohjelma koneen muistiin. Vain vuosi Manchester Mark I:n julkaisun jälkeen, julkaistiin USA:ssa kilpaileva tietokone, EDSAC (Electronic Delay Storage Automatic Computer). Nämä ensimmäiset tietokoneet olivat huoneen kokoisia laitoksia, jotka perustuivat elektroniputkitekniikkaan. Ohjelmointikielet ottivat ison harppauksen kehityksessään eteenpäin, kun vuonna 1957 julkaistiin ensimmäinen FORTRAN kääntäjä. Tämä merkitsi sitä, että ennen niin harvoille ja erikoistuneille ohjelmoijille varattu ohjelmointityö alkoi kehittyä käyttäjäystävällisemmäksi ja helpommaksi. Edsger Dijkstra oli ensimmäinen, joka alkoi puhua tarpeesta ohjelmakoodin rakenteistamiseksi (1968). Tästä sai alkunsa GO TO -lauseen kritisointi ja rakenteisen ohjelmoinnin kehittäminen. Rakenteisen suunnittelun periaatteita opiskellaan myöhemmin tälläkin kurssilla. Tietokoneiden historia on kulkua entistä pienempiin, tehokkaampiin ja suurimuistisimpiin koneisiin. Vuonna 1963 sovittiin ASCII -standardista, joka tarkoitti ensimmäistä kertaa sitä, että eri valmistajien tietokoneet saattoivat vaihtaa tietoa keskenään. Ensimmäisen todellisen minitietokoneen, PDP-8, julkaisi Digital Equipment Corporation vuonna Henkilökohtaisen tietokoneen juuret ovat vuodessa 1971, jolloin tuli markkinoille ensimmäinen kaupallinen mikroprosessori ja ensimmäinen levyke. Ensimmäinen digitaalinen, henkilökohtainen tietokone oli MITS 816 (1972), jossa tosin ei ollut näyttöä eikä näppäimistöä. IBM julkaisi ensimmäisen henkilökohtaisen tietokoneen nimeltä 5100 vuonna 1975, Apple II julkaistiin vuonna 1976 ja IBM julkaisi Personal Computer eli PC:n, jonka käyttöjärjestelmänä oli Microsoftin kehittämä DOS, vuonna Nykyisen graafisen käyttöliittymän juuret ovat vuodessa 1984, jolloin Apple julkaisi Macintosh in. Siinä oli sekä hiiri että käyttöliittymän ikonit. Huhutaan, että todellinen kehitystyö olisi kuitenkin tehty Xerox PARCin toimesta, Alto -järjestelmän kehittämisen yhteydessä. 1.2 Tietojärjestelmien historia Tietojärjestelmä sanana viittaa tiedon käsittelemiseen. Perusoperaatioita ovat tiedon talletus, säilytys, haku ja poisto. Lisäoperaatioita ovat erilaiset laskutoimitukset, joita tietojen avulla voidaan tehdä. Tietojärjestelmälle ei kuitenkaan ole olemassa vakiintunutta määritelmää. Toiset rajaavat tietojärjestelmän käsitteen tietokoneella toteutettuun järjestelmään, kun toiset taas ymmärtävät sillä mitä tahansa tiedon talletukseen, varastointiin, muokkaukseen ja hakemiseen tarkoitettu järjestelmää. Laajemman määritelmän mukaan tietojärjestelmän ei tarvitse olla toteutettu tietokoneella, vaan esimerkiksi arkistokaappi tai puhelinluettelo täyttävät tietojärjestelmän määritelmän. Kaikkein laajin määritelmä sisällyttää tietojärjestelmän käsitteeseen koko organisaation: ihmiset, heidän työnsä sekä kaikki ne apuvälineet, joita tuossa työssä käytetään. Edellisestä ilmiöstä johtuu, että tietojärjestelmien historia ei ole välttämättä aivan sama asia kuin tietokoneen historia. Ihmiset ovat kautta vuosisatojen pyrkineet varastoimaan tietoa erilaisille tietovälineille. Tässä mielessä tietojärjestelmien historia on lähes yhtä pitkä kuin ihmisenkin historia. Savitauluja käytettiin kirjanpidon apuvälineenä muinaisessa Babyloniassa jo 3000 vuonna ekr. 4

5 Tietokonetuettujen tietojärjestelmien historia on puolestaan verraten lyhyt - tosin kehitys on ollut nopeaa verrattuna moneen muuhun alueeseen luvulla tietotekniikan käyttö yrityksissä oli vähäistä ja sitä käytettiin lähinnä laskennan apuvälineenä luvulla tulivat yrityksiin tietojenkäsittelyosastot luvulla yleistyivät varsinaiset tietokonepohjaiset tietojärjestelmät. Järjestelmät olivat yleensä eräajopohjaisia, osastojen sisäisiä järjestelmiä luvulla tulivat henkilökohtaiset tietokoneet ja tietoverkot alkoivat kehittyä ja yleistyä luvulla tietokonetta sovelletaan organisaatioissa jo lähes kaikilla työn osa-alueilla. Tietoverkot eivät rajoitu enää edes yrityksen sisäisten toimintojen tukemiseen, vaan ne ovat laajentuneet yrityksen ulkopuolelle. Suurilla tuotantoyrityksillä on esimerkiksi useita alihankkijoita, joiden kanssa kommunikoidaan tietotekniikan välityksellä. Useimmiten myös pankkiasiat hoidetaan yrityksestä käsin tietotekniikan avulla. Tietoverkkojen laajeneminen yritysten ulkopuolelle mahdollistaa myös työntekijöiden työskentelemisen fyysisesti yrityksen ulkopuolella. Tietotekniikka mahdollistaa etätyön tekemisen esimerkiksi työntekijän kotona. Työntekijä voi tehdä työtään yrityksen tietojärjestelmissä kotoaan käsin, jos hänellä on siihen tarvittavat laitteet. Tietojärjestelmien suunnittelu ja rakentaminen edellyttää useiden alueiden tietämystä. Relevantteja tietämysalueita voisivat olla esimerkiksi tietojärjestelmän tulevien käyttäjien toimintatavat, algoritmit ja tietorakenteet, ohjelmisto-, tietokone- ja tietojärjestelmäarkkitehtuuri sekä yrityksen liiketoiminnan sovellusalue. 1.3 Tietojärjestelmien kehittäminen Tietojärjestelmän määritelmä vaikuttaa suoraan siihen, mitä tietojärjestelmien kehittämisellä tarkoitetaan. Jos tietojärjestelmää ajatellaan tietokonepohjaisena järjestelmänä, on kehittämisen kohteena luonnollisesti tietokonepohjainen sovellus. Tuon sovelluksen oletetaan tukevan jotain tiettyä toimintaa. Jos tietojärjestelmät ymmärretään laajemmin käsittäen kaikki tiedon hallintaan liittyvät välineet, on kehittäminenkin määriteltävä laajemmin. Tietojärjestelmien kehittäminen olisi tässä tapauksessa tiettyyn ihmisen toimintaan liittyvien tiedonhallintavälineiden kehittämistä - oli ne sitten toteutettu tietokoneella tai ei. Tästä jälkimmäisestä määritelmästä on se etu, että tietojärjestelmien analysointi ja suunnittelu voi olla kokonaisvaltaisempaa ja mahdollisten kehittämistoimenpiteiden kohde on laajempi. Laajimmillaan tietojärjestelmien kehittämisellä voidaan ymmärtää koko organisaation toiminnan kehittämistä. Tällöin ihmisten tekemää työtä ei oteta annettuna, vaan kaikkia työhön liittyviä osa-alueita voidaan kehittää: niin työn tekemisen apuvälineitä kuin työntekijöiden käsityksiä heidän työnsä tavoitteista. Nykyään yritykset keskittyvät yhä enemmän toimintansa kehittämiseen. Syitä tähän ovat nopeutunut kehitys, laatuajattelu, kova kilpailu ja taloudelliset tekijät. Yritysten toiminnan kehittämiseen liittyvät ongelmat ovat moninaiset. Tietämys työn tekemisestä saattaa olla myös pirstaloitunutta; yksittäiset työtekijät tekevät vain erikoistuneita tehtäviä, mutta kokonaisuus ei välttämättä ole kenenkään hallussa. Työn siirtyessä henkilöltä toiselle tehtävien alustus- ja lopetusoperaatioita saattaa olla paljon, mikä hidastaa työn kulkua. Toiminta voi olla byrokraattista ja hierarkioita voi olla paljon, mikä saattaa tehdä organisaation toiminnan suhteellisen jäykäksi. Organisaatioissa 5

6 tehdään usein myös päällekkäistä työtä, vaikka saman asian tekeminen vain yhteen kertaan olisikin edullisempaa. Lisäksi pitkälle erikoistunut työnjako ja tiedonkulun heikkoudet saattavat aiheuttaa sen, että asiakaspalvelun taso on heikkoa. Tämä taas vähentää yrityksen kiinnostavuutta ja kilpailukykyä. Yrityksen toiminnan, tuotteiden ja palvelujen laatu syntyy sen prosessien ominaisuuksista, pelkät resurssit eivät riitä. Tietotekniikka on yksi keino kehittää näitä prosesseja suoraan esimerkiksi nopeuttamalla tiedonkäsittelyä ja tiedon saatavuutta tai välillisesti esimerkiksi tarjoamalla työntekijöille hyödyllisiä työvälineitä ja lisäämällä heidän mahdollisuuksiaan tehostaa prosesseja oman työnsä osalta. Tosin tietotekniikan kehittäminen harvoin yksin riittää. Liiketoimintaa on usein kehitettävä kokonaisvaltaisesti. Teknologian kehittymisen myötä yrityksissä keskitytään nykyisin enemmän toiminnan kehittämiseen, kun taas aikaisemmin keskityttiin enemmän tekniseen kehittämiseen. Tämä johtuu mm. siitä, että tietotekniikan soveltaminen olemassa olevien työtapojen tukemiseen on huomattu johtavan suhteellisen huonoihin lopputuloksiin. Työt kyllä saadaan tällaistenkin järjestelmien avulla tehtyä. Tosin vaihtoehtoinen ratkaisu, jossa työn rakenteita ensin muutetaan ja järjestelmä rakennetaan tukemaan uutta toimintamallia, johtaa toiminnan tehostumiseen. Kilpailutilanteissa, jossa kilpailijat tehostavat toimintaansa ja alentavat hintojaan, organisaatioiden kannattaa usein muuttaa toimintatapojaan tietokonepohjaisten tietojärjestelmien kehittämisen yhteydessä. 2 TIETOJÄRJESTELMIEN KEHITTÄMINEN Tässä luvussa kuvataan tietojärjestelmien suunnittelun taustoja ja elinkaarimalli karkealla tasolla. Lisäksi pohditaan projektityöskentelyä tietojärjestelmäsuunnittelun yhteydessä. Tietojärjestelmien suunnittelua on tutkittu ja erilaisia suunnittelumenetelmiä kehitetty jo 1950-luvulta lähtien. Jotkut suunnittelijat keskittyvät tietojärjestelmien suunnittelussa ainoastaan teknisiin ongelmiin, toiset puolestaan tietojärjestelmän strategisiin vaikutuksiin organisaatiossa, toiset kustannusten pienentämiseen ja toiset työn muutoksiin. Kuitenkin nämä kaikki tulisi ottaa huomioon. Täydellisempi kuva tietojärjestelmän suunnitteluprosessista saadaan, kun identifioidaan nämä erilaiset näkökulmat ja selvitetään niiden väliset suhteet. Suunnitteluprosessin ymmärtäminen helpottuu, kun tutkitaan järjestelmän suunnittelun elinkaarta (life cycle). Järjestelmän elinkaari sisältää kaikki suunnitteluprosessin vaiheet ongelman havaitsemisesta valmiiseen ja toimivaan järjestelmään. Kaikista elinkaarimalleista voidaan identifioida viisi päävaihetta: toiminnan tai ongelma-alueen analysointi sekä järjestelmän suunnittelu, toteutus, käyttöönotto ja ylläpito. Valittaessa menetelmää tietojärjestelmien suunnitteluun on muistettava, että erilaisia menetelmiä käytetään erilaisissa tilanteissa. Rakennettaessa suuria rakenteeltaan tarkasti määrättyjä tietojärjestelmiä käytetään muodollisempia suunnittelumenetelmiä. Suunnittelumenetelmästä riippumatta on aina muistettava, että tietojärjestelmä rakennetaan ratkaisemaan oikeaa ongelmaa. Järjestelmän täytyy sopia olemassa olevaan ympäristöön ja tulevien käyttäjien työtehtäviin. 6

7 Tietojärjestelmien suunnittelumenetelmä voidaan määritellä yhtenäiseksi joukoksi käsitteitä, uskomuksia, arvoja ja periaatteita, jotka auttavat ongelmaa ratkaisevaa ryhmää havaitsemaan, tuottamaan, arvioimaan ja toteuttamaan muuten kuin satunnaisella tavalla muutoksia informaatiotilanteessa. Menetelmä on siis enemmän kuin joukko ohjeita selvitä erilaisista ongelmista. Yhtä ainoaa oikeaa menetelmää ei ole olemassa, vaan jokaisella menetelmällä on oma, suhteellisen erilainen teoria maailmasta. Koska tietojärjestelmän rakentaminen vie paljon aikaa, järjestelmät ovat laajoja ja rakentaminen itsessään on suhteellisen monimutkaista, jaetaan kehittämisprojektit usein osiin. Näin on kehitetty erilaisia vaihejakoja systemointia varten. Koska vaihejaot yleensä noudattavat järjestelmän ajallista kehitystä, niitä kutsutaan myös elinkaarimalleiksi (life cycle models). 3.1 Lineaarinen elinkaari Lineaarinen elinkaari on perinteinen lähestymistapa tietojärjestelmien suunnittelussa. Sen vaiheet ovat peräkkäisiä ja seuraava vaihe perustuu aina edellisen tuloksiin. Kunkin vaiheen tuloksena on jonkinlainen raportti (kuvaukset, päätökset, ongelmat), joten dokumentoinnilla on tärkeä osa suunnittelussa. Seuraavassa esitetään yksi mahdollinen lineaarinen elinkaarimalli. Vaihe 1: Tehtävän määrittely Tehtävän määrittely on ehkä vaiheista tärkein. Tässä vaiheessa määritellään ratkaistava ongelma, sen rajat, suunnittelun tavoitteet ja käytettävät resurssit. Itse ongelman määrittely ei välttämättä ole yksinkertainen tehtävä. Se, mikä tässä vaiheessa ymmärretään ratkaistavaksi ongelmaksi, saattaa kehitystyön edetessä paljastua huonoksi määrittelyksi. Tehtävänä voisi olla esimerkiksi suunnitella uusi myyntitoimintaa tukeva järjestelmä, josta olisi apua sekä operatiiviseen myyntitoimintaan että markkinoinnin suunnitteluun. Ongelman ulkopuolelle voitaisiin rajata laskutukseen liittyvät toiminnot, joita varten on jo olemassa oma järjestelmänsä. Näin ongelmaalueen sisälle voisi kuulua automaattinen liittymä näiden kahden ohjelmiston välillä. Tehtävän määrittelyvaiheessa tehdään usein myös projektisuunnitelma, jossa määritellään mm. tarvittavat resurssit. Projektin tulosten seuranta ja arviointi tapahtuvat usein tehtävän määrittelyn perusteella. Vaihe 2: Toteutettavuustutkimus Toteutettavuustutkimusvaiheessa laaditaan ehdotus periaateratkaisuksi ja esitetään idea järjestelmän rakenteesta ja toteutuksesta. Tietojärjestelmän toteutettavuuteen liittyvät seuraavat näkökohdat: tekninen (löytyykö taitoa ja teknologiaa) toiminnallinen (käyttäjien hyväksyntä) taloudellinen (projektin resurssitarve). 7

8 Vaihe 3: Järjestelmän analyysi Järjestelmän analyysivaiheessa tutkitaan olemassa olevaa järjestelmää (siltä osin kuin se on olemassa) keräämällä tietoa eri lähteistä. Tässä vaiheessa suoritetaan tietoanalyysi ja laaditaan järjestelmän yksityiskohtainen malli käyttäen erilaisia kuvaustekniikoita. Vaihe 4: Järjestelmän suunnittelu Järjestelmän suunnitteluvaihe voidaan jakaa kahteen alavaiheeseen: Yleissuunnittelu, jossa selvitetään järjestelmän päätoiminnot, tärkeimmät syötteet ja tulosteet sekä erotetaan automatisoitavat ja manuaaliset osat. Yksityiskohtainen suunnittelu, jonka tuloksena määritellään tietokannat, ohjelmamoduulit, proseduurit, laitteet, käyttöliittymät, käyttöohjeet ja lomakkeet. Vaihe 5: Järjestelmän rakentaminen Järjestelmän rakentaminen voidaan jakaa kahteen alavaiheeseen: Kehittäminen, jossa kirjoitetaan ohjelmat, ladataan tietokannat ja testataan käyttöliittymät. Implementointi, jossa kootaan osat toimivaksi järjestelmäksi. Vaihe 6: Seuranta Järjestelmän oltua jonkin aikaa toiminnassa tarkistetaan, onko tavoitteet saavutettu. Jos asetettuja tavoitteita ei ole saavutettu, etsitään epäonnistumisen syitä. Tässä vaiheessa järjestelmään voidaan tehdä pieniä korjauksia, mutta pahimmassa tapauksessa tulisi aloittaa uusi kehityssykli. Käytännössä tähän ei usein ole mahdollisuutta, sillä projekti voi olla jo muutenkin ylittänyt suunnitellun budjettinsa. On hyvin tyypillistä, että tehtävän määrittelyvaiheessa ei osata arvioida tulevaa työmäärää oikein. Lisäksi käyttäjien koulutus hoidetaan usein aivan liian kevyesti, mikä huonontaa uuden järjestelmän vastaanottoa. Vaihe 7: Ylläpito Ylläpitovaiheessa korjataan käytössä havaittuja virheitä, viritetään ja sovitetaan valmista järjestelmää ympäristön ja muuttuneiden tarpeiden mukaisesti. 8

9 Tehtävän määrittely Käyttäjien vaatimukset Reunaehdot: -Projektin tavoite -Projektin rajat -Resurssit Tarkista Jatkoimplementointi Toteutettutkimus tavuus- Järjestelmäanalyysi Käsitteellinen ratkaisu Arvioidut kustannukset ja hyödyt Tarkista Oikeellisuus Implementointi Yleissuunnittelu Tietomalli Järjestelmän yksityiskohtaiset tavoitteet Tarkista Oikeellisuus Järjestelmän suunnittelu Tarkista Käyttäjien tehtävät Ehdotetut laitteistot Ohjelma- ja tietokantamääritykset Oikeellisuus Oikeellisuus Tarkista Kehittäminen Järjestelmän rakentaminen Seuranta Yksityissuunnittelu kohtainen Ylläpito Toimiva järjestelmä Oikeellisuus Kuva 3.1. Lineaarinen elinkaarimalli Lineaarisen elinkaaren suunnitteluvaiheiden puhdas peräkkäisyys ei aina käytännössä toimi, vaan suunnittelijan pitää voida perääntyä ja tarkistaa aiemmissa vaiheissa tehtyjä ratkaisuja. Yleensä paluu tapahtuu edeltävään vaiheeseen, jolloin elinkaaresta käytetään nimitystä 'loopy linear' (silmukkainen lineaarinen). Esimerkiksi jos järjestelmän rakentamisvaiheessa huomataankin, ettei aiemmin suunniteltua tietomallia voidakaan toteuttaa, on palattava suunnitteluvaiheeseen. Toisaalta odottamattomat ongelmat järjestelmän käytössä voivat aiheuttaa paluun järjestelmän toteutusvaiheeseen, suunnitteluvaiheeseen tai jopa analyysivaiheeseen. Mitä aikaisemmaksi elinkaaressa joudutaan palaamaan, sitä suuremmasta ja kalliimmin ratkaistavasta ongelmasta todennäköisesti on kysymys. Pahin tilanne on tietysti silloin, kun huomataan, että itse projektin tavoite on ollut pielessä. Kuvassa 3.2 on esitelty joitakin lineaarisen elinkaarimallin käytössä mahdollisesti esiintyviä ongelmatilanteita, jotka saattavat vaatia paluun aikaisempaan vaiheeseen. 9

10 Tehtävän määrittely Järjestelmä ei täytä operationaalisia eikä taloudellisia vaatimuksia Tietomallia ei voida rakentaa Toteutettutkimus tavuus- Järjestelmän analyysi Järjestelmän suunnittelu Tarvitaan enemmän tietoa järjestelmästä Suunnitelmia ei voida implementoida Odottamattomia ongelmia valmiissa järjestelmässä Järjestelmän rakentaminen Kuva 3.2. Lineaarisen elinkaarimallin ongelmia. Klassisen vaihejaon noudattamisessa on se vaara, että suunnittelija luulee vaihejaon sinänsä takaavan hyvän lopputuloksen. Tämä ei tietenkään itsessään riitä. Vaihejako on hallinnollisesti selkeä, mutta dokumentoinnin osuus on ylikorostunut - usein kehitystyön kustannuksella. Dokumentoinnin tulisi olla vain sivutuote. Eräs ilmaus perinteisen suunnittelutavan ongelmista on ylläpidon osuus, joka nykyisin nielee jopa 70 % järjestelmän kokonaiskustannuksista. Eräänä syynä on ollut se, että elinkaaren alkupäähän ei ole panostettu riittävästi. Analyysiin ja suunnitteluun on käytetty ehkä noin 20 % kokonaispanoksesta, kun nykyisen käsityksen mukaan osuuden tulisi olla jopa 70-80%. Käyttäjien osuus perinteisessä suunnittelumetodiikassa on ollut liian pieni. On oletettu, että käyttäjät osaavat ilmaista tarpeensa analyysivaiheessa tarkasti. Tämä ei yleensä pidä paikkaansa, joten käyttäjien tulisi voida osallistua aktiivisesti koko prosessiin. Jos käyttäjien tarpeiden määrittelyssä tehdään virheitä, sillä on laajakantoinen vaikutus lopputulokseen. Myös organisaation johdon tulee olla mukana ja sitoutua tehtyihin ratkaisuihin. Klassinen menetelmä on eräänlainen 'big bang' -lähestymistapa; järjestelmä tehdään kerralla valmiiksi ja käyttäjä tutustuu siihen vasta toteutuksen jälkeen. Toteutuksen jälkeen on kuitenkin liian myöhäistä enää tehdä kovin syvällisiä muutoksia. Klassinen vaihejako ei sisällä varsinaista suunnitelmien testausvaihetta ennen järjestelmän rakentamista. Kuitenkin on todettu, että noin 64 % virheistä tehdään analyysi- ja suunnitteluvaiheissa ja vain 36 % ohjelmoinnissa. Lineaarisen elinkaarimallin yhteydessä esille nousseiden ongelmien ratkaisemiseksi on vaihtoehtoiseksi lähestymistavaksi esitetty evoluutionaarista kehittämisratkaisua. Tällöin tietojärjestelmän kehittäminen ei tapahdu järjestelmän kertakaikkisena 10

11 implementointina, vaan järjestelmää kehitetään osaprosesseina, joiden tulosta evaluoidaan ja tämän jälkeen tuotetta kehitetään edelleen. Esimerkiksi protoilu (prototyyppisuunnittelu) toteuttaa evoluutionaarista kehittämisperiaatetta. Protoilu on prosessi, joka antaa järjestelmäkehittäjän mahdollisuuden luoda mallin, prototyypin, rakennettavasta järjestelmästä (ohjelmasta). Tätä mallia arvioidaan yhdessä tulevien käyttäjien kanssa ja mallin pohjalta kehitetään edelleen uusi malli, joka edellistä paremmin vastaa tilaajan vaatimuksia. Kuvassa 3.3 on hahmoteltu prototyypin käyttöön perustuvaa tietojärjestelmän kehittämisprosessia Pressmanin (1992) mukaan. Määrittely Lopullinen toteutus pika design Proton uudell. määrittely Proton evaluointi (käyttäjät/tilaaja) Proton rakentaminen Kuva 3.3. Protoilun käyttö tietojärjestelmän kehittämisessä. Prototyypit voi jakaa toteutustavan mukaan kahteen pääryhmään horisontaalisiin ja vertikaalisiin prototyyppeihin. Horisontaalisessa prototyypissä mallinnetaan toiminnallinen kokonaisuus mutta jätetään mallintamatta järjestelmän yksityiskohdat. Vertikaalisessa prototyypissä puolestaan valitaan mallinnettava osa-alue ja implementoidaan se kokonaisuudessaan, pienintä yksityiskohtaa myöten. Spiraalimalli pitää sisällään useita protoilun elementtejä. Spiraalimalli on protoilua strukturoidumpi tietojärjestelmän kehittämismalli. Kehittäminen lähtee liikkeelle suunnitteluvaiheesta. Ensimmäinen kierros perustuu suunnittelun tuloksiin. Riskianalyysin jälkeen tehdään päätös kehittämisen jatkamisesta. Kehittämisvaiheessa luodaan prototyyppi. Asiakas / tilaaja arvioi prototyypin toimintaa. Tämän jälkeen palataan suunnitteluvaiheeseen, tosin jo toiselle kierrokselle. Toisella kierroksella vastaavat vaiheet ja muutettavat osa-alueet perustuvat jo asiakkaan kommentteihin. Spiraali etenee sisäkehältä ulospäin. Kehittämisprojektin ja tuloksena olevan tuotteen luonteesta riippuu spiraalin kierrosten määrä. 11

12 3.2 Tietojärjestelmäprojekti Projekteista ja projektinhallinnasta on olemassa runsaasti materiaalia. Tämä pitää paikkansa myös tietojärjestelmäprojektien osalta. Ei ole kuitenkaan perusteltua ottaa mitään lähestymistapaa absoluuttisena totuutena. Projekti käsitteenä on laajasti käytetty ja ymmärretty mutta sen eksakti ja tässä yhteydessä käyttökelpoinen määrittely ei enää olekaan yhtä triviaali. Forsman määrittelee projektin tarkoittamaan työn tekemistapaa ja rakennetta seuraavine tunnuspiirteineen. Projekti on ainutlaatuinen ja ainutkertainen Projekti tähtää sovittuun lopputulokseen Projektilla on sovittu aikataulu Projektin voimavarat ovat lyhytvaikutteisia. Projektisuunnitelman laatiminen on merkittävin yksittäinen toimenpide kehitysprojektia käynnistettäessä. Seuraava projektisuunnitelma on muokattu Pressmanin (1992) ohjelmistoprojektin suunnitelmasta. Kyseinen suunnitelma nojautuu varsin pitkälle lineaariseen elinkaarimalliin. Toisaalta evolutionaarisen kehittämisparadigman käyttö on mahdollista varsin pienin muutoksin suunnitelman perusrakenteeseen. Projektisuunnitelma aloitetaan johdannolla, jossa kerrotaan dokumentin tarkoitus (kuvata tietojärjestelmän kehitysprojekti), määritellään projektin tavoitteet ja ongelmaalue sekä projektin ulkopuolelle jäävät asiat. Ongelma-aluetta kannattaa havainnollistaa sekä kuvin että sanoin. Kaikenlaisen taustatiedon antaminen on vain hyväksi ja nostaa dokumentin luettavuutta ja laatua. Myös projektin rajaus on tärkeää, koska sen perusteella saadaan parempi käsitys siitä, mihin projektilla todella tähdätään ja mihin ei. Projektin rajauksen syitä kannattaa pohtia kuten myös vaihtoehtoisia rajauksia. Projektin ulkopuolelle jäävistä ongelmista kannattaa myös antaa mahdollisimman tarkka selonteko. Projektisuunnitelma voi jatkua esittelemällä projektiin liittyvät riskit. Riskianalyysissä tulisi keskustella niin teknisistä kuin sosiaalisistakin riskeistä. Kannattaa pohtia, onko rakennettava järjestelmä teknisesti mahdollinen, liittyykö tekniikkaan riskejä, onko projektin käytössä riittävästi tietämystä käytetyistä tekniikoista, millaisia sosiaalisia vaikutuksia tulevalla järjestelmällä voi olla, onko todennäköistä, että käyttäjät tulevat hyväksymään järjestelmän ja niin edelleen. Suuret riskit eivät välttämättä tarkoita sitä, että projektia ei kannattaisi toteuttaa. Riskien tiedostaminen ja analysointi on kuitenkin osa hyvää projektinhallintaa. Lisäksi riskien hallintaan liittyvä suunnitelma on kuitenkin hyvä esittää. Projektisuunnitelmassa esitetään myös suunnitelma projektin aikatauluksi. Aikataulun suunnittelu on erittäin vaikea tehtävä ja se arvioidaankin hyvin usein liian pieneksi. 12

13 Varsinkin, jos projektisuunnitelman tekijällä ei ole aikaisempaa kokemusta aikatauluista, kannattaa projektisuunnitelma tarkistuttaa jollain kokeneella henkilöllä. Jos projektisuunnitelmaa käytetään tarjouksen laskentaan, tulee aikataulun suhteen olla erityisen tarkka. Aikataulu esitetään usein osatehtävittäin. Aikataulusta käy myös ilmi osatehtävien suoritusjärjestys, niiden tulokset sekä tarkistuspisteet. Työn tulos tulee aina tarkastaa määräajoin. Tällaisella käytännöllä voidaan välttää ainakin osa budjettiin liittyvistä epäselvyyksistä. Projekti on voitava ja uskallettava myös lopettaa tarkastuspisteissä, jos sen tulokset eivät tyydytä. Projektisuunnitelmassa on esitettävä, miten projektia valvotaan ja miten sen toimintaa ohjataan. Projektin resurssien kuvaus kuuluu myös projektisuunnitelmaan. Suunnitelmasta tulee käydä ilmi, ketkä henkilöt ottavat osaa projektiin ja millaisin panoksin. Jos esimerkiksi joku tuleva käyttäjä on osa projektiryhmää, on huolehdittava, että hän saa helpotusta päivittäisten tehtäviensä hoitoon. Myös johtajien ja kehittäjien panokset projektiin tulee arvioida. Projektit tarvitsevat usein myös muita resursseja: laitteistoja, projektihuoneen, erilaisia mallinnusvälineitä sekä mahdollisesti lisäkoulutusta. Projekteille on tapana muodostaa myös itsenäinen organisaatiorakenne. Projektilla on tyypillisesti johtaja, jäseniä sekä ohjausryhmä. Ohjausryhmä valvoo projektin toimintaa, eikä ota varsinaisesti osaa tuloksen tekemiseen. Projektin organisaatiokaavio esitetään tyypillisesti projektisuunnitelmassa. Alla on hahmoteltuna projektisuunnitelman runko karkealla tasolla. 13

14 1. Johdanto Dokumentin tarkoitus Projektin tavoitteiden määrittely Projektin rajaus 2. Projektin riskit Riskien analysointi Riskinhallinta 3. Aikataulu Aikataulu osatehtävittäin Osatehtävien suoritusjärjestys Osatehtävien vaatimat resurssit 4. Resurssit Henkilöresurssit Resurssit 5. Organisaatio Projektiorganisaation kuvaus 6. Valvonta- ja ohjausjärjestelmät Liitteet Lähteet: Forsman, Ulf. Hahmotelma korkeakoulujen talouden ja taloudenpidon malliksi, Computer Science University of Turku Research reports R-94-13, Pressman Roger S., Software engineering a practitioner s approach. McGraw-Hill int.,

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston 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ätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot

Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit

Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit Kurssilla: Johdatus käyttäjäkeskeiseen tuotekehitykseen 23.1.2008 Johanna Viitanen johanna.viitanen@soberit.hut.fi Luennon aiheet Tuotekehityksen

Lisätiedot

Luku 6 Projektisuunnitteluvaihe

Luku 6 Projektisuunnitteluvaihe Luku 6 Projektisuunnitteluvaihe Projektisuunnittelu Project Planning Projektin Project Definition määrittely and ja Planning suunnittelu Projektin Initiate käynnistäminen andja organisointi Project Organize

Lisätiedot

Koodaamme uutta todellisuutta FM Maarit Savolainen https://blog.edu.turku.fi/matikkaajakoodausta/

Koodaamme uutta todellisuutta FM Maarit Savolainen https://blog.edu.turku.fi/matikkaajakoodausta/ Koodaamme uutta todellisuutta FM Maarit Savolainen 19.1.2017 https://blog.edu.turku.fi/matikkaajakoodausta/ Mitä on koodaaminen? Koodaus on puhetta tietokoneille. Koodaus on käskyjen antamista tietokoneelle.

Lisätiedot

Standardi IEC Ohjelmisto

Standardi IEC Ohjelmisto Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

Tik-76.612 Ohjelmistoprojektien Hallinta

Tik-76.612 Ohjelmistoprojektien Hallinta Tik-76.612 Ohjelmistoprojektien Hallinta Tervetuloa kurssille! 2 Kurssin yleisinfo Kurssin tausta Katsaus luentoihin Aloitusluennon agenda Luennoitsijoiden esittely Harjoitustyön läpikäynti Muut käytännön

Lisätiedot

A11-02 Infrapunasuodinautomatiikka kameralle

A11-02 Infrapunasuodinautomatiikka kameralle A11-02 Infrapunasuodinautomatiikka kameralle Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Lassi Seppälä Johan Dahl Sisällysluettelo Sisällysluettelo 1. Projektityön tavoite

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

11/20: Konepelti auki

11/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ätiedot

Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus

Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus 10.2.2016 Hakuprosessi Rahoitusta tutkimukseen ja innovointiin 4. Lataa hakemus osallistujaportaaliin

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

Lisätiedot

Keksijän muistilista auttaa sinua jäsentämään keksintöäsi ja muistuttaa asioista, joita on hyvä selvittää.

Keksijän muistilista auttaa sinua jäsentämään keksintöäsi ja muistuttaa asioista, joita on hyvä selvittää. Keksijän muistilista auttaa sinua jäsentämään keksintöäsi ja muistuttaa asioista, joita on hyvä selvittää. Oletko tehnyt uuden keksinnön ja mietit, miten tehdä keksinnöstäsi liiketoimintaa? Miten keksintöäsi

Lisätiedot

Interfacing Product Data Management System

Interfacing Product Data Management System Interfacing Product Data Management System Tekijä: Työn valvoja: Mats Kuivalainen Timo Korhonen Esitelmän sisältö Työn suorituspaikka - Ideal Product Data Oy Käsitteitä Työn tavoitteet Työn tulokset 1/5

Lisätiedot

L models. Käyttöohje. Ryhmä Rajoitteiset

L models. Käyttöohje. Ryhmä Rajoitteiset Teknillinen korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Käyttöohje Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset 0.1

Lisätiedot

Laatukäsikirja - mikä se on ja miten sellainen laaditaan?

Laatukä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ätiedot

Automaattinen yksikkötestaus

Automaattinen 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ätiedot

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä $$$ Raha ratkaisee On vaara rakastua tekniikkaan, myös asiakkailla Kaikki pitää pystyä perustelemaan taloudellisesti Projektin toteutus yleensä -> voidaan jättää toteuttamatta, jos ei maksa itseään takaisin

Lisätiedot

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen 16.06.2014 Ohjaaja: Urho Honkanen Valvoja: Prof. Harri Ehtamo Työn saa tallentaa ja julkistaa Aalto-yliopiston

Lisätiedot

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma. 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ätiedot

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1

Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Harri Laine 1 Ohjelmistojen mallinnus (OMa) - Johdatus ohjelmistotuotantoon 31.10.2008 Harri Laine 1 Ohjelmisto Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän

Lisätiedot

C++ Ohjelmoijan käsikirja. Johdanto

C++ Ohjelmoijan käsikirja. Johdanto Johdanto C++ Ohjelmoijan käsikirja Johdanto Tervetuloa Inside C++-kirjan pariin. Tämä on opaskirja standardi C++:n käyttöön. Käsittelemme kirjassa kaikki syntaksin, kieliopin, olio-ohjelmoinnin ja standardikirjastojen

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen 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ätiedot

Harjoitustyö Case - HelpDesk

Harjoitustyö 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ätiedot

Ohjelmointi 1 / syksy /20: IDE

Ohjelmointi 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ätiedot

Tietotekniikan Sovellusprojektit

Tietotekniikan Sovellusprojektit Tietotekniikan Sovellusprojektit Jukka-Pekka Santanen Tietotekniikan laitos 16.2.2010 Tavoitteena taitoja ja kokemusta projektimuotoisesta työtavasta ja ryhmätyöstä, projektin hallinnasta ja johtamisesta,

Lisätiedot

Ohjelmoinnin perusteet Y Python

Ohjelmoinnin perusteet Y Python Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2009 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2009 1 / 28 Puhelinluettelo, koodi def lue_puhelinnumerot(): print "Anna lisattavat nimet ja numerot." print

Lisätiedot

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Tä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ätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta

Lisätiedot

Tik Harjoitustyö

Tik Harjoitustyö Tik-76.612 Harjoitustyö Harjoitustyön uusi aikataulu Ti 12.3 Kurssin aloitus Harjoitustyön läpikäynti To 14.3 Ti 19.3 Projektin synty Projektisuunnitelma Ryhmien muodostuminen To 21.3 Ti 26.3 To 4.4 Ti

Lisätiedot

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun

Lisätiedot

Haaga-Helia / TIKO-05 1 (12) Tietokannan suunnittelu ja Toteutus Outi Virkki

Haaga-Helia / TIKO-05 1 (12) Tietokannan suunnittelu ja Toteutus Outi Virkki Haaga-Helia / TIKO-05 1 (12) Tietotarpeet Tietotarpeiden määrittely... 2 Tietotarveanalyysi... 3 Lähtökohtana tietojenkäsittelytehtävät... 3 Määrittelyn sisältö... 4 Vaiheistus... 5 Tietolähteet... 5 Lähestymistapa...

Lisätiedot

Tutkimusmenetelmät-kurssi, s-2004

Tutkimusmenetelmät-kurssi, s-2004 Algoritmitutkimuksen menetelmistä Tutkimusmenetelmät-kurssi, s-2004 Pekka Kilpeläinen Kuopion yliopisto Tietojenkäsittelytieteen laitos Algoritmitutkimuksen menetelmistä p.1/20 Sisällys Tänään Tietojenkäsittelytiede

Lisätiedot

Oliotietokannat. Nääsvillen Oliopäivät Pekka Kähkipuro Kehitysjohtaja, FT

Oliotietokannat. Nääsvillen Oliopäivät Pekka Kähkipuro Kehitysjohtaja, FT Oliotietokannat Nääsvillen Oliopäivät 2004 15.12.2004 Pekka Kähkipuro Kehitysjohtaja, FT pekka.kahkipuro@sysopen.fi Oliotietokanta Idea: pysyvän tiedon tallentaminen suoraan oliomuodossa Tietosisältö ja

Lisätiedot

Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus

Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus Hakeminen käytännössä: osallistujaportaali ja hakemuksen kirjoittaminen Elina Holmberg Infotilaisuus 24.8.2016 Hakuprosessi Rahoitusta tutkimukseen ja innovointiin 4. Lataa oma hakemuksesi osallistujaportaaliin

Lisätiedot

Eräs tyypillinen virhe monitavoitteisessa portfoliopäätösanalyysissa + esimerkkitapaus

Eräs tyypillinen virhe monitavoitteisessa portfoliopäätösanalyysissa + esimerkkitapaus Eräs tyypillinen virhe monitavoitteisessa portfoliopäätösanalyysissa + esimerkkitapaus Mat-2.4142 Optimointiopin seminaari 2.3.2011 Lähteet: Clemen, R. T., & Smith, J. E. (2009). On the Choice of Baselines

Lisätiedot

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla

Lisätiedot

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7 Viitearkkitehtuurin suunnitteluprosessi Ohje v.0.7 Viitearkkitehtuurin suunnitteluprosessi XX.XX.201X 2 (13) Sisällys 1. Johdanto... 3 2. Viitearkkitehtuurin suunnitteluprosessin vaiheet... 3 2.1. Vaihe

Lisätiedot

työssäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan. Ammattitaidon osoittamistavat

työssäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan. Ammattitaidon osoittamistavat 1(6) TYÖSSÄOPPIMINEN JA AMMATTIOSAAMISEN NÄYTTÖ Tutkinnon osa: Palvelinohjelmistojen ja virtualisointi 15 osp Työssäoppimisen keskeinen sisältö: työtehtävien suunnittelu ja valmistelu oman työn ja työn

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmä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ätiedot

Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA

Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA PROJEKTITOIMINNAN ONGELMIA Kaikkea mahdollista nimitetään projekteiksi Projekti annetaan henkilöille muiden töiden ohella Ei osata käyttää

Lisätiedot

HELIA 1 (13) Outi Virkki Tietokantasuunnittelu

HELIA 1 (13) Outi Virkki Tietokantasuunnittelu HELIA 1 (13) Luento 2 Tietotarpeiden määrittely... 2 Tietotarveanalyysi... 3 Lähtökohtana tietojenkäsittelytehtävät... 3 Määrittelyn sisältö... 4 Lähestymistapa... 5 Tietolähteet... 5 Vaiheistus... 5 Tietotarpeen

Lisätiedot

BaRE Käyttövalmis vaatimusmäärittelymenetelmä

BaRE Käyttövalmis vaatimusmäärittelymenetelmä BaRE Käyttövalmis vaatimusmäärittelymenetelmä Uolevi Nikula, Tietotekniikan osasto, LTKK, Uolevi.Nikula@lut.fi 13.11.2002 un/tsoft 1 Esityksen sisältö Jatko-opinnot Lisensiaatintutkimus BaRE menetelmä

Lisätiedot

Plagiointi opintosuorituksissa TaY:n plagiointityöryhmän toimenpide-ehdotuksia

Plagiointi opintosuorituksissa TaY:n plagiointityöryhmän toimenpide-ehdotuksia TAUCHI Tampere Unit for Computer-Human Interaction Plagiointi opintosuorituksissa TaY:n plagiointityöryhmän toimenpide-ehdotuksia Veikko Surakka Research Group for Emotions, Sociality, and Computing Tampere

Lisätiedot

Software engineering

Software engineering Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of

Lisätiedot

Kieliaineistojen käyttöoikeuksien hallinnan tietojärjestelmä

Kieliaineistojen 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ätiedot

SOPIMUS [SOVELLUSHANKINNASTA]

SOPIMUS [SOVELLUSHANKINNASTA] Julkisen hallinnon IT- hankintojen sopimusehdot (JIT 2007) 1 ----------------------------------------------------------------------------------------------------------------------------------- [JHS 166

Lisätiedot

Avoimen ohjelmistotuotteen hallinta julkisella sektorilla. Jukka Kääriäinen VTT Oy , Oskari-verkostopäivä

Avoimen ohjelmistotuotteen hallinta julkisella sektorilla. Jukka Kääriäinen VTT Oy , Oskari-verkostopäivä Avoimen ohjelmistotuotteen hallinta julkisella sektorilla Jukka Kääriäinen (jukka.kaariainen@vtt.fi) VTT Oy 19.5.2015, Oskari-verkostopäivä Esityksen sisältö Mitä on tuotteenhallinta? Mikä on avoimen tuotteenhallintamalli?

Lisätiedot

Prosessiajattelu. Organisaation prosessikuvaus - CMMI. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessien määritys CMMI käytänteet

Prosessiajattelu. Organisaation prosessikuvaus - CMMI. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessien määritys CMMI käytänteet Organisaation prosessikuvaus - CMMI Prosessikuvaukset ja elinkaarimallit Sami Kollanus TJTA330 Ohjelmistotuotanto 7.2.2007 Level5 Level4 Level3 Requirements Development Technical Solution Product Integration

Lisätiedot

Ideasta hankkeeksi Kulttuurihankkeen suunnittelu Novgorod 2013 Marianne Möller

Ideasta hankkeeksi Kulttuurihankkeen suunnittelu Novgorod 2013 Marianne Möller Ideasta hankkeeksi Kulttuurihankkeen suunnittelu Novgorod 2013 Marianne Möller 23.9.2013 Hankeidea Hankesuunnitelma budjetti yhteistyösopimus Esityksen sisältö Hankkeen toteuttaminen tavoitteet ja välitavoitteet

Lisätiedot

Ohjelemistotuotanto, syksy 1998 /Prosessi Prosessimallit

Ohjelemistotuotanto, syksy 1998 /Prosessi Prosessimallit Prosessimallit Prosessimalli on ohjelmiston elinkaaren rakenteen määrittely ts. kuvaus sille millaisten vaiheiden kautta ohjelmisto kehittyy ideasta hautaan mahdollisimman yleisesti sovellettavissa oleva

Lisätiedot

Johdatus rakenteisiin dokumentteihin

Johdatus rakenteisiin dokumentteihin -RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista

Lisätiedot

SOVELLUSPROJEKTIN ARVIOINTILOMAKE

SOVELLUSPROJEKTIN ARVIOINTILOMAKE SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa

Lisätiedot

Rekisterit tutkimusaineistona: tieteenfilosofis-metodologiset lähtökohdat

Rekisterit tutkimusaineistona: tieteenfilosofis-metodologiset lähtökohdat Reijo Sund Rekisterit tutkimusaineistona: tieteenfilosofis-metodologiset lähtökohdat Rekisterit tutkimuksen apuvälineenä kurssi, Biomedicum, Helsinki 25.05.2009 Kevät 2009 Rekisterit tutkimusaineistona

Lisätiedot

WWW-osoite Virallinen sähköpostiosoite Emoyhtiön konsernin nimi Yksikön nimi. Diaari /0/2014

WWW-osoite Virallinen sähköpostiosoite Emoyhtiön konsernin nimi Yksikön nimi. Diaari /0/2014 Hakemuksen tiedot Onko kyseessä Tutkimusorganisaatio Rahoitus yliopistoille, ammattikorkeakouluille ja muille tutkimusorganisaatioille Strategiseen tutkimusavaukseen Organisaation tiedot Perustiedot Y-tunnus

Lisätiedot

Käytännön haasteita ja ratkaisuja integraation toteutuksessa. Jukka Jääheimo Teknologiajohtaja Solita Oy

Käytännön haasteita ja ratkaisuja integraation toteutuksessa. Jukka Jääheimo Teknologiajohtaja Solita Oy Käytännön haasteita ja ratkaisuja integraation toteutuksessa Jukka Jääheimo Teknologiajohtaja Solita Oy 13.03.2008 Sisältö 2 Alustus Integraation haasteet Integraatioarkkitehtuuri Hyvän integraatioarkkitehtuurin

Lisätiedot

TIETOKANNAT: MYSQL & POSTGRESQL Seminaarityö

TIETOKANNAT: MYSQL & POSTGRESQL Seminaarityö TIETOKANNAT: MYSQL & POSTGRESQL Seminaarityö Tekijät: Eemeli Honkonen Joni Metsälä Työ palautettu: SISÄLLYSLUETTELO: 1 SEMINAARITYÖN KUVAUS... 3 2 TIETOKANTA... 3 2.1 MITÄ TIETOKANNAT SITTEN OVAT?... 3

Lisätiedot

2. Ohjelmistotuotantoprosessi

2. Ohjelmistotuotantoprosessi 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

Arjen elämyksistä globaalia bisnestä klo 12 alkaen

Arjen elämyksistä globaalia bisnestä klo 12 alkaen Arjen elämyksistä globaalia bisnestä 29.1.2015 klo 12 alkaen Oulun Kaupunginteatteri, Pikisali #northernserviceday Yhteinen ymmärrys asiakkaan kanssa ja oman organisaation sisällä Oulu 29.1.2015 Marja

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä

Oliosuunnitteluesimerkki: 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ätiedot

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka

Lisätiedot

JÄRJESTELMÄTYÖKALUT SEKÄ SOVELLUSTEN POISTAMINEN

JÄRJESTELMÄTYÖKALUT SEKÄ SOVELLUSTEN POISTAMINEN JÄRJESTELMÄTYÖKALUT SEKÄ SOVELLUSTEN POISTAMINEN Tämänkertaisen tehtävän aiheena ovat sovellusten lisäys/poisto sekä Windowsin mukana tulevat järjestelmätyökalut, jotka löytyvät valinnan Käynnistä Apuohjelmat

Lisätiedot

Käyttötapausanalyysi ja testaus tsoft

Käyttötapausanalyysi ja testaus tsoft Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten

Lisätiedot

VERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D

VERSIONHALLINTA. 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ätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

työssäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan

työssäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan 1(7) TYÖSSÄOPPIMINEN JA AMMATTIOSAAMISEN NÄYTTÖ Tutkinnon osa: Palvelujen käyttöönotto ja tuki Tutkinnon osaan kuuluvat opinnot: Työasemaympäristön suunnittelu ja toteuttaminen Kouluttaminen ja asiakastuki

Lisätiedot

Luku 8. Aluekyselyt. 8.1 Summataulukko

Luku 8. Aluekyselyt. 8.1 Summataulukko Luku 8 Aluekyselyt Aluekysely on tiettyä taulukon väliä koskeva kysely. Tyypillisiä aluekyselyitä ovat, mikä on taulukon välin lukujen summa tai pienin luku välillä. Esimerkiksi seuraavassa taulukossa

Lisätiedot

11. Javan toistorakenteet 11.1

11. Javan toistorakenteet 11.1 11. Javan toistorakenteet 11.1 Sisällys Laskuri- ja lippumuuttujat. Sisäkkäiset silmukat. Tyypillisiä ohjelmointivirheitä: Silmukan rajat asetettu kierroksen verran väärin. Ikuinen silmukka. Silmukoinnin

Lisätiedot

Uutta Remote Support Platform 3.0 -versiossa

Uutta Remote Support Platform 3.0 -versiossa Uutta Remote Support Platform for SAP Business One Asiakirjaversio: 1.0 2012-10-08 Kaikki maat Typografiset merkintätavat Kirjasintyyli Esimerkki Näytöstä lainatut sanat tai merkit. Näitä ovat kenttien

Lisätiedot

Lähestymistavat - toiminnallinen

Lähestymistavat - toiminnallinen Lähestymistavat - toiminnallinen Systeemiteoreettinen lähestymistapa INPUT PROCESS OUTPUT systeemi on prosessi, joka saa syötteitä ja tuottaa tuloksia systeemi voidaa jakaa osasysteemeihin tietojärjestelmissä

Lisätiedot

Prosessiajattelu. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessikuvaus - CMMI. Sami Kollanus TJTA330 Ohjelmistotuotanto 3.4.

Prosessiajattelu. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessikuvaus - CMMI. Sami Kollanus TJTA330 Ohjelmistotuotanto 3.4. Prosessikuvaukset ja elinkaarimallit Sami Kollanus TJTA330 Ohjelmistotuotanto 3.4. Organisaation prosessikuvaus - CMMI Level5 Level4 Organizational Innovation and Deployment Causal Analysis and Resolution

Lisätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

Lisätiedot

Action Request System

Action Request System Action Request System Manu Karjalainen Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 25.10.2000 Action Request System (ARS) Manu Karjalainen Ohjelmistotuotantovälineet

Lisätiedot

Laadunvarmistuksen merkitys toimitusketjussa. Fingrid: Omaisuuden hallinnan teemapäivä. Kaj von Weissenberg

Laadunvarmistuksen merkitys toimitusketjussa. Fingrid: Omaisuuden hallinnan teemapäivä. Kaj von Weissenberg Laadunvarmistuksen merkitys toimitusketjussa Fingrid: Omaisuuden hallinnan teemapäivä Kaj von Weissenberg 19.5.2016 1 Lisää Inspectasta Luomme turvallisuutta, luotettavuutta ja kestävää kehitystä Pohjois-Euroopassa

Lisätiedot

Luku 10 Käyttöönoton suunnitteluja toteutusvaihe

Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Käyttöönoton Roll-Out Planning suunnittelu- & Preparation ja valmistelu Design Tiedon- Data Conversion muunnos- prosessien Processes suunnittelu Toimipisteiden

Lisätiedot

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Muutamia ajatuksia siitä, miten testaus pärjää lama-ajan säästötalkoissa. Laman patologioita ja mahdollisuuksia. Säästämisen strategioita.

Lisätiedot

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure Automaattinen regressiotestaus ilman testitapauksia Pekka Aho, VTT Matias Suarez, F-Secure 2 Mitä on regressiotestaus ja miksi sitä tehdään? Kun ohjelmistoon tehdään muutoksia kehityksen tai ylläpidon

Lisätiedot

Talousjohtaja strategiavaikuttajana: Kohti dialogista johtamista? Eero Vaara

Talousjohtaja strategiavaikuttajana: Kohti dialogista johtamista? Eero Vaara Talousjohtaja strategiavaikuttajana: Kohti dialogista johtamista? Eero Vaara http://www.hanken.fi/staff/vaara Strategisen johtamisen ongelmia» Toiminnallistamisen ( implementointi, jalkauttaminen ) vaikeudet»

Lisätiedot

Esimerkkejä polynomisista ja ei-polynomisista ongelmista

Esimerkkejä polynomisista ja ei-polynomisista ongelmista Esimerkkejä polynomisista ja ei-polynomisista ongelmista Ennen yleisempiä teoriatarkasteluja katsotaan joitain tyypillisiä esimerkkejä ongelmista ja niiden vaativuudesta kaikki nämä ongelmat ratkeavia

Lisätiedot

Kurssin sisältö. Kurssilla vähemmän. Johdatus ohjelmistotekniikkaan. Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan?

Kurssin sisältö. Kurssilla vähemmän. Johdatus ohjelmistotekniikkaan. Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan? Kurssin sisältö Johdatus ohjelmistotekniikkaan 2 0 0 8 Mitä on ohjelmistotekniikka? Miten ohjelmistoja suunnitellaan ja toteutetaan? Mitä työkaluja ohjelmistoja kehitettäessä käytetään ja miten? Historiaa

Lisätiedot

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004 Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen

Lisätiedot

Käsitteistä. Reliabiliteetti, validiteetti ja yleistäminen. Reliabiliteetti. Reliabiliteetti ja validiteetti

Käsitteistä. Reliabiliteetti, validiteetti ja yleistäminen. Reliabiliteetti. Reliabiliteetti ja validiteetti Käsitteistä Reliabiliteetti, validiteetti ja yleistäminen KE 62 Ilpo Koskinen 28.11.05 empiirisessä tutkimuksessa puhutaan peruskurssien jälkeen harvoin "todesta" ja "väärästä" tiedosta (tai näiden modernimmista

Lisätiedot

Mallintarkistus ja sen

Mallintarkistus ja sen VERSIO 0.1 LUONNOS Mallintarkistus ja sen soveltaminen PLCohjelmien verifioinnissa AS-0.3200 Automaatio- ja systeemitekniikan projektityöt -projektisuunnitelma Markus Hartikainen 2/1/2009 Sisältö 1. Projektityön

Lisätiedot

Tiedote 13.8.2013. Projekti I -kurssin Tilaajalle

Tiedote 13.8.2013. Projekti I -kurssin Tilaajalle Tiedote 13.8.2013 Projekti I -kurssin Tilaajalle Projekti I on tietojenkäsittelytieteiden laitoksen (TOL) pääaineopiskelijoille tarkoitettu, pakollinen, 7 op:n opintojakso ajoitettuna 3. opintovuodelle.

Lisätiedot

Harjoitus 7: NCSS - Tilastollinen analyysi

Harjoitus 7: NCSS - Tilastollinen analyysi Harjoitus 7: NCSS - Tilastollinen analyysi Mat-2.2107 Sovelletun matematiikan tietokonetyöt Syksy 2006 Mat-2.2107 Sovelletun matematiikan tietokonetyöt 1 Harjoituksen aiheita Tilastollinen testaus Testaukseen

Lisätiedot

YRITTÄJÄTESTIN YHTEENVETO

YRITTÄJÄTESTIN YHTEENVETO YRITTÄJÄTESTIN YHTEENVETO Alla oleva kaavio kuvastaa tehdyn testin tuloksia eri osa-alueilla. Kaavion alla on arviot tilanteestasi koskien henkilökohtaisia ominaisuuksiasi, kokemusta ja osaamista, markkinoita

Lisätiedot

työssäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan. Ammattitaidon osoittamistavat

työssäoppimispaikan työtehtävissä toimiminen ammattiosaamisen näytön suorittaminen näyttösuunnitelman mukaan. Ammattitaidon osoittamistavat 1(7) TYÖSSÄOPPIMINEN JA AMMATTIOSAAMISEN NÄYTTÖ Tutkinnon osa: Sähköisten toteuttaminen 15 osp Työssäoppimisen keskeinen sisältö: työtehtävien suunnittelu ja valmistelu oma-aloitteisuus ja työn tulosten

Lisätiedot

Matematiikan tukikurssi

Matematiikan tukikurssi Matematiikan tukikurssi Kurssikerta 4 Jatkuvuus Jatkuvan funktion määritelmä Tarkastellaan funktiota f x) jossakin tietyssä pisteessä x 0. Tämä funktio on tässä pisteessä joko jatkuva tai epäjatkuva. Jatkuvuuden

Lisätiedot

Tuotantotalouden analyysimallit. TU-A1100 Tuotantotalous 1

Tuotantotalouden analyysimallit. TU-A1100 Tuotantotalous 1 Tuotantotalouden analyysimallit TU-A1100 Tuotantotalous 1 Esimerkkejä viitekehyksistä S O W T Uudet tulokkaat Yritys A Yritys B Yritys E Yritys C Yritys F Yritys I Yritys H Yritys D Yritys G Yritys J Alhainen

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

Lisätiedot

Agenda. Läpäisyvaatimukset Henkilökunta Luennot ja aikataulu Kurssimateriaali Harjoitustyöt Demoharjoitus Tentti ja arvostelu Muuta?

Agenda. Läpäisyvaatimukset Henkilökunta Luennot ja aikataulu Kurssimateriaali Harjoitustyöt Demoharjoitus Tentti ja arvostelu Muuta? OHJ-4301 Sulautettu Ohjelmointi (http://www.cs.tut.fi/~sulo/) 5op, to 12-14, 14, TB 109 Arto Salminen, arto.salminen@tut.fi Agenda Läpäisyvaatimukset Henkilökunta Luennot ja aikataulu Kurssimateriaali

Lisätiedot

Satunnaisalgoritmit. Topi Paavilainen. Laskennan teorian opintopiiri HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Satunnaisalgoritmit. Topi Paavilainen. Laskennan teorian opintopiiri HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Satunnaisalgoritmit Topi Paavilainen Laskennan teorian opintopiiri HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Helsinki, 23. helmikuuta 2014 1 Johdanto Satunnaisalgoritmit ovat algoritmeja, joiden

Lisätiedot

Varoitukset turvallisuusjohdon työkaluina

Varoitukset turvallisuusjohdon työkaluina Varoitukset johdon työkaluina Juuso Lehtinen jalehtin@cc.hut.fi Kirja - Warnings and Risk Communication Useita kirjoittajia Toimittanut Michael S. Wogalter David M. DeJoy Kenneth R. Laughery Julkaisija:

Lisätiedot

Rakennusautomaation käytettävyys. Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT

Rakennusautomaation käytettävyys. Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT Rakennusautomaation käytettävyys Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT 2 Oma tausta Perusinsinööri DI, lvi-tekniikka, TKK 1993 Herääminen käytettävyysasioihin noin 2002 Tekniikan

Lisätiedot

PARTIOJOHTAJAPERUSKURSSIN JOHTAMISHARJOITUS

PARTIOJOHTAJAPERUSKURSSIN JOHTAMISHARJOITUS PARTIOJOHTAJAPERUSKURSSIN JOHTAMISHARJOITUS Johtamisharjoituksen tavoitteet Johtamisharjoituksen eli ns. välitehtävän tarkoitus on antaa sinulle onnistunut kokemus johtamisesta partiossa. Harjoituksen

Lisätiedot

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn

Lisätiedot

T harjoitustehtävät, syksy 2011

T harjoitustehtävät, syksy 2011 T-110.4100 harjoitustehtävät, syksy 2011 Kurssiassistentit Tietotekniikan laitos Perustieteiden korkeakoulu Aalto-yliopisto T-110.4100@tkk.fi Yleistä Kurssin osasuoritteita ovat kaksi osatenttiä ja harjoitustehtävät

Lisätiedot