Ohjelmistotekniikka - Luento 14 Jouni Lappalainen

Koko: px
Aloita esitys sivulta:

Download "Ohjelmistotekniikka - Luento 14 Jouni Lappalainen"

Transkriptio

1 Ohjelmistotekniikka - Luento 14 Jouni Lappalainen Luku 28: Riskien hallinta - reaktiivinen ja proaktiivinen riskien hallinta - riskien tunnistus, arviointi ja tarkentaminen - riskien vähentäminen, valvonta ja hallinta (MMM), RMMM suunnitelma Luku 29: Ylläpito ja uudelleensuunnittelu - ylläpito - liiketoimintaprosessin ja ohjelmiston uudelleensuunnittelu - takaisinmallintaminen/käänteistekniikka Luku 30: Ohjelmistoprosessin parantaminen - menetelmiä ja malleja - kyvykkyysmalli CMMI

2 Core Body of Knowledge Areas Graduate Software Engineering 2009 (GSwE2009) Curriculum Guidelines for Graduate Degree Programs in Software Engineering Integrated Software & Systems Engineering Curriculum (issec) Project 2

3 Soveltuvat lait ja pohdiskelun aiheita 1. Projektiriskit voidaan ratkaista tai niitä voidaan lieventää, kun ne tunnistetaan aikaisessa vaiheessa /hyp_no 17, Boehm Pienissä muutoksissa on suurempi virhetiheys kuin suurissa muutoksissa / no 30, Basili&Perricone 1984, Möller 1995

4 Soveltuvat lait ja pohdiskelun aiheita Mitkä kahdeksan omiin kokemuksiin perustuvaa, COTS perustaisten järjestelmien ylläpitoon liittyvää oppimaa Reifer et al. oheisessa paperissa esittävät? Buschmann esittelee kahdessa paperissaan kolme arkkitehtuurin hoitamiseen (gardening) ja parantamiseen liittyvää periaatetta, refaktoroinnin (refactoring), uudelleensuunnittelun (reengineering) ja uudelleen kirjoittamisen (rewriting). Kerro, mitä niillä tarkoitetaan ja miten ne pitäisi suorittaa, jos haluaa tehdä ne hyvin. ) Jacobson et al. esittelevät Semat periaatteen (Semat ydin & käsitemalli) oheisessa paperissa. Mitä etuja Semat ydin tarjoaa käyttäjälle tekijöiden mukaan? Mitä tarkoitetaan käsitteellä alpha? Miten tiimin tilannetta voidaan arvioida Semat korttien avulla?

5 28. Projektin riskien hallinta Mikä voi mennä pieleen?!! Millä todennäköisyydellä?!!miten pahasti?!!miten siitä selvitään?! 5

6 Mitä riskillä tarkoitetaan? Riscare (uskaltaa / to dare) -> risk If there is no choice, there is no risk, even though there may be loss incurred (Charette 1989) jos valinnan mahdollisuutta ei ole, ei ole myöskään mahdollisuutta välttää tulevia tapahtumia Yleinen määritelmä: the possibility of loss or injury tappion tai vahingon mahdollisuus

7 Negatiivinen / positiivinen riski Negatiivinen riski tavoitteena ymmärtää mahdolliset ongelmat jotka voivat sattua projektissa ja kuinka ne voivat estää projektin onnistumisen negatiivinen riskinhallinta voidaan nähdä eräänlaisena vakuutuksena Riski voi olla positiivinen positiiviset riskit aiheuttavat toteutuessaan hyviä asioita, ne voidaan nähdä mahdollisuutena riskinhallinnan tavoitteena on minimoida mahdollisia negatiivisia riskejä ja maksimoida positiivisia

8 Johdon osuus onnettomuuksiin In the inquiries into numerous major accidents, including the Chernobyl nuclear explosion, the sinking of the Herald of Free Enterprise, the Challenger space shuttle explosion, and the Piper Alpha oil rig fire, senior management failure was concluded to be a primary cause / Redmill 2002 Johdon toiminnasta aiheutuva häiriö Inhimillinen virhe Laitevika Käytetty työpanos Todellinen tärkeys Challenger onnettomuudessa NASA:n insinööreillä oli onnettomuuden todennäköisyydestä arvio 1:200 (parhaimmillaan 1:1000), mutta johdolla arvio 1:

9 Reaktiivinen riskien hallinta projekti reagoi riskeihin niiden lauetessa vähentäminen resursseja myös tulen sammutuksen ennakointiin häiriön poisto resursseja on käytettävissä, kun riski laukeaa kriisin hallinta häiriötä ei saada kuriin ja projekti on vaarassa

10 Proaktiivinen riskien hallinta tehdään riskianalyysi korjataan riskien aiheuttajat Total Quality Management (TQM) ja tilastollinen laadunvarmistus tutkitaan ohjelmiston ulkopuoliset riskien aiheuttajat kehitetään muutosten hallinnan taitoja

11 Seitsemän periaatetta /SEI Kokonaisvaltainen tarkastelu view software risks within the context of system and the business problem Ennakoiva tarkastelu think about the risks that may arise in the future; establish contingency plans Avoin kommunikointi if someone states a potential risk, don t discount it. Integrointi a consideration of risk must be integrated into the software process Jatkuva prosessi the team must be vigilant (tarkkaavainen) throughout the software process, modifying identified risks as more information is known and adding new ones as better insight is achieved. Yhteinen näkemys tuoteesta if all stakeholders share the same vision of the software, it likely that better risk identification and assessment will occur. Tiimityön rohkaisu the talents, skills and knowledge of all stakeholder should be pooled 11

12 Risk Assessment Methodology/NIST - hakkerit - teollisuusvakoilu - palomuuri - käyttäjätunnukset - SQL injektio Järjestelmän tarkoituksen määrittely Uhkien tunnistus Haavoittuvuuksien tunnistus Valvonnan analyysi Todennäköisyyden määrittely Vaikutusanalyysi RE = P * C Riskien määrittely Suositeltu valvonta Tulosten dokumentointi Stoneburner, Goguen, Feringa, Risk Management Guide for Information Technology Systems, 2002

13 Riskiin varautuminen Riskiin (riskin laukeamiseen) varautuminen! RE (risk exposure) määritellään kaavalla [Hall 1998]:!!!RE = P x C! missä!! P todennäköisyys riskin laukeamisesta! C kustannus projektille riskin lauetessa.!! 13

14 Riskiin varautumisen aste (risk exposure) Kustannus Todennäköisyys Pieni Keskisuuri Korkea Pieni Pieni Pieni Keskisuuri Keskisuuri Pieni Keskisuuri Suuri Suuri Keskisuuri Suuri Suuri

15 Yleisimpiä riskejä ja niiden hallintakeinoja Avainhenkilö vaihtaa työpaikkaa Epärealistiset aikataulut ja budjetit Kehitetään vääriä toimintoja ja turhia piirteitä Huono käyttöliittymä Muutokset määrittelyissä Ongelmat muualta hankituissa komponenteissa ja/tai palveluissa Tekniset ongelmat (suoritusteho, reaaliaikaisuus, muistitila, epäkypsä teknologia) Tehtävien kierto, varahenkilöt, sopimustekniset keinot Huolellinen projektisuunnittelu, inkrementit, ketterät menetelmät Prototyyppien käyttö, ketterät menetelmät, markkinatutkimukset Prototyyppien käyttö, ulkopuoliset asiantuntijat, käyttäjän työskentelyn analysointi Prototyyppien käyttö, ketterät menetelmät, muutosten byrokratisointi ja rahastus, huolellinen määrittely Referenssiasiakkaiden hyödyntäminen, suorituskyvyn ja toiminnallisuuden testaus, yhteensopivuuden varmistaminen, toimittajan laatujärjestelmän arviointi Simulointi, mallintaminen, prototyypit, referenssiasiakkaiden hyödyntäminen perustuu lähteisiin Boehm 1989 ja Haikala & Märijärvi 2000

16 Syklomaattinen kompleksisuus Suoritettavia lauseita C++ koodi esimerkki (315 moduulia) 0 ei riskiä 1 pieni riski 2 pienikeskink. riski 3 keskinkertainen riski 4 keskink. - korkea riski 5 korkea riski 6 hyvin korkea riski moduulien määrä % osuus Ohjelmamoduulien riskialttius Software Assurance Technology Center (SATC) tutkimus / Buttigieg A.D.

17 11 tärkeintä ohjelmistoprojektin riskitekijää Keil M., Cule P., Lyytinen K., Schmidt R., Communications of the ACM, no 11,1998

18 Riskien tunnistus / Keil et al Ovatko tärkeimmät päälliköt (sekä ohjelmiston kehittämisen että asiakkaan puolella) sitoutuneet projektin tukemiseen? 2. Ovatko loppukäyttäjät innostuneesti sitoutuneet projektiin ja rakennettavaan järjestelmään/ tuotteeseen? 3. Ymmärtävätkö ohjelmistotuotantotiimi ja asiakkaat täysin vaatimukset? 4. Ovatko asiakkaat täysin mukana vaatimusten määrittelyssä? 5. Ovatko loppukäyttäjien odotukset realistisia? 18

19 Riskien tunnistus / Keil et al Onko projektin tarkoitus vakaa? 7. Onko ohjelmistotuotantotiimissä oikea sekoitus osaamista? 8. Ovatko projektin vaatimukset vakaita? 9. Onko projektiryhmässä kokemusta käytettävästä teknologiasta? 10. Onko projektiryhmän koko riittävä tehtävään nähden? 11. Ovatko asiakkaan ja käyttäjän edustajat yhtä mieltä projektin tärkeydestä ja rakennettavan järjestelmän/tuotteen vaatimuksista? 19

20 Riskien luokittelu / U.S. Air Force suorituskykyriski tuote ei ehkä täytä vaatimuksia ja eikä sovi tarkoitukseen. kustannusriski projektin budjettia täytyy mahdollisesti päivittää. tukiriski ohjelmistoa voi olla hankala korjata, sovittaa käyttöön ja laajentaa. aikatauluriski projektin aikataulu ei ehkä pidä eikä tuotetta toimiteta ajoissa. 20

21 Riskien välttäminen, valvonta ja hallinta (Risk Mitigation, Monitoring and Management) mitigation kuinka riskejä voidaan välttää? monitoring mitä tekijöitä seuraamalla voidaan ennustaa riskien laukeamista? management millaisia varasuunnitelmia on, jos riskit toteutuvat?

22 Riskien luettelointi Riskit Luokittelu Todennäköisyys Vaikutus RMMM Kokoarvio liian pieni Käyttäjiä arvioitua enemmän Uudellenkäyttöä arvioitua vähemmän Julkistusaikaa aikaistetaan Rahoitusongelmia Käyttäjä muuttaa vaatimuksia Teknologia ei vastaa odotuksia PS PS PS BU FU PS TE 60 % 30 % 70 % 50 % 40 % 80 % 30 % Vaikutus 4 = katastrofaalinen 3 = kriittinen 2 = pieni 1 = vähäinen Luokittelu PS = Project size risk BU = Business risk FU = Funding risk TE = Technical risk

23 Riskin raportointilomake Tunnus: < numero tai tunniste > Kuvaus: < milloin riskitilanne syntyy - mitä siitä aiheutuu > (esim. kaikki asiakkaat eivät ole tyytyväisiä tuotteelle asetettuihin vaatimuksiin, voimme toteuttaa vain tärkeimmän asiakkaan vaatimukset) Todennäköisyys: Kustannus: Riskiin varautuminen: < todennäköisyys * kustannus > Ensimmäinen indikaattori: < mikä voi ilmaista riskin muuttumista ongelmaksi > Kuinka välttää: < millä toimilla riskin vaikutusta voi vähentää tai välttää > Vastuuhenkilö: < kuka on vastuussa Milloin: < milloin viimeistään riskin vähentämistoimista> vähentämistoimet täytyy tehdä >

24 Esimerkki riskin laukeamiseen varautumisesta Riskin tunnistaminen: Vain 70 prosenttia komponenteista, joita on suunniteltu käytettäväksi sovelluksen rakentamisessa, voidaan todellisuudessa käyttää. Loput toiminnallisuudesta joudutaan rakentamaan sovellusta varten. Riskin todennäköisyys: 80 % Riskin vaikutus: Sovelluksen rakentamisessa suunnitellaan käytettäväksi 60 ohjelmistokomponenttia. Jos vain 70 % voidaan käyttää, 18 komponenettia joudutaan rakentamaan sovellusta varten. Kun komponentin keskimääräinen koko on 100 LOC ja jos (kokemuksen mukaan) ohjelmiston rakentaminen maksaa 15 euroa / LOC, niin kokonaiskustannukset komponenttien rakentamiselle on 18 * 100* 15 = euroa Riskin laukeamiseen varautuminen (Risk exposure) RE = 0.80 x ~ euroa. 24

25 29. Ylläpito ja uudelleensuunnittelu ylläpito ja Lehmanin lait liiketoimintaprosessin ja ohjelmiston uudelleensuunnittelu takaisinmallintaminen/käänteistekniikka 25

26 Ohjelmiston ylläpito Muutokset ohjelmistoon ovat väistämättömiä katso Lehmanin lait E-tyypin järjestelmille Ylläpidon luokittelu on elänyt ajan kuluessa Swanson 1976 esitteli kolme: korjaavan, mukauttavan ja täydellistävän Pfleeger 1998 esitteli neljä: korjaavan, mukauttavan, ennalta ehkäisevän ja täydellistävän Sommerville 2004 ei suosittele luokittelun käyttöä, koska on sitä on vaikea käyttää kiistattomasti oikein Korjaus Laajennus Proaktiivinen Reaktiivinen Ennalta ehkäisevä (preventive) Korjaava (corrective) Täydellistävä (perfective) Mukauttava (adaptive) eteenpäin suunnittelu (forward engineering) on lähinnä ennalta ehkäisevää (preventive) ja täydellistävää (perfective)

27 Lehmanin lait 1. Jatkuvan muutoksen laki E-tyypin järjestelmiä täytyy jatkuvasti sovittaa käyttöön, muuten ne tulevat käyttökelvottomiksi 2. Kasvavan mutkikkuuden laki Kun E-tyypin järjestelmä elää, sen mutkikkuus kasvaa - jossakin vaiheessa sitä täytyy parantaa tai se täytyy hylätä 3. Itsesäätelyn laki Globaalin E-tyypin järjestelmän evoluutioprosessi on itseään säätävä 4. Organisationaalisen pysyvyyden laki Keskimääräinen globaalin toiminnan määrä on kehittyvän E- tyypin järjestelmässä muuttumaton koko järjestelmän elinjakson ajan

28 Lehmanin lait 5. Tuttuuden säilyttämisen laki Uusien piirteiden määrä E-tyypin järjestelmän uusissa julkaisuissa on vakio koko järjestelmän aktiivisen elämän ajan 6. Jatkuvan kasvun laki E-tyypin järjestelmien toiminnallisuuden täytyy jatkuvasti lisääntyä, jotta käyttäjät pysyvät tyytyväisinä 7. Laadun heikentyminen E-tyypin järjestelmien laatu huononee, kunnes järjestelmää korjataan ja sovitetaan ympäristössä tapahtuneisiin muutoksiin 8. Takaisinkytketyn järjestelmän laki E-tyypin järjestelmien evoluutioprosessi on monitasoinen, monisilmukkainen ja moniagenttinen takaisinkytketty järjestelmä ja sitä pitää kohdella sellaisena, jota muutokset tai parannukset onnistuvat

29 Esimerkki elinkaarikustannusten jakautumisesta (Schach 2005) % ylläpitotyöstä kuluu ylläpidettävän järjestelmän ymmärtämiseen ohjelmiston elinjakson pituus vaikuttaa ylläpidon osuuteen aikana tehdyissä mitauksissa ylläpidon osuus oli 67 % aikana tehdyissä mitauksissa ylläpidon osuus kasvoi ja oli 75 % ohjelmiston kehitysvaiheiden työmäärissä ei tapahtunut suuria muutoksia ylläpito koostuu (räätälöidylle) virheiden korjauksista (17 %) asiakkaan toiminnan ja ympäristön muuttumisen vaatimista korjauksista (18 %) uusien piirteiden lisäämisestä (65 %)

30 Ylläpidon työpanos koko ohjelmiston elinaikana 100 % Korjaava ylläpito Mukauttava ylläpito 90 % 80 % 70 % 60 % Täydellistävä ylläpito 50 % 40 % 30 % 20 % 10 % Ajankohta, kun täydellistävä vie 65 %, korjaava 17 % ja mukauttava 18 %? aika Wiederholdin (2006) esitystä mukaellen

31 Uudelleensuunnittelu Liiketoiminta prosessit# Tieto- järjestelmät# Uudelleensuunnittelu# Ohjelmisto- sovellukset# 31

32 Liiketoimintaprosessin uudelleensuunnittelu Tehdään tarkennukset (protoiluun perustuen) ja otetaan uusi prosessi käyttöön Liiketoiminnan määrittely Tavoitteet - kustannusten pienentäminen - ajan lyhentäminen - laadun parannus - henkilöstön kehittäminen Testataan uutta prosessia protoilemalla Tarkennus ja käyttöönotto Tunnistetaan kriittiset prosessit tavoitteiden saavuttamiseksi Protoilu Tuotetaan käyttötapaukset uudelleensuunniteltaville prosesseille, Niiden avulla suunnitellaan uudet tehtävät. Prosessin määrittely ja suunnittelu Prosessin arviointi Prosessin tunnistus Tunnistetaan prosessin tehtävät ja niiden kustannukset ja ajantarpeet. Tunnistetaan laatuja suorituskykyongelmat. 32

33 Ohjelmiston uudelleensuunnittelu Muokataan ohjelmistoa laadun parantamiseksi ja ylläpidon helpottamiseksi. Siirrytään esim. asiakas/palvelin arkkitehtuuriin tai palvelupohjaiseen arkkitehtuuriin. Esim. tiedostot korvataan tietokannalla. Muutokset voivat aiheuttaa muutoksia arkkitehtuuriin ja koodiin refaktorointi tiedon" uudelleen-" muotoilu" eteenpäin" suunnittelu! uudelleen-" koodaus! inventointi! uudelleen-" dokumentointi! Arvioidaan kaikki sovellukset - tarpeellisuus - ylläpidettävyys (katso kuvaus) kuinka paljon, kuinka täydellisesti takaisinmallintaminen! Ohjelmasta tuotetaan suunnittelutason kuvaus (katso kuvaus) 33

34 Olemassaolevien järjestelmien arviointi Koska järjestelmä on yritykselle tärkeä mutta huonolaatuinen (ylläpito kallista) kannattaa uudelleensuunnitella tai korvata uudella Järjestelmä pitää säilyttää toimintakunnossa, mutta tavalliset ylläpitotoimet riittävät Arvokas yritykselle & Laadultaan huono Arvokas yritykselle & Laadultaan hyvä Liiketoiminnan arvo Ei tärkeä yritykselle & Laadultaan huono Ei tärkeä yritykselle & Laadultaan hyvä Niin kauan kun tavalliset ylläpitotoimet riittävät, kannattaa pitää käytössä Laadultaan huonoa järjestelmää & yritykselle arvotonta ei kannata pitää toiminnassa Järjestelmän laatu Sommerville 2004

35 Takaisinmallintaminen / käänteistekniikka (reverse engineering) vain rakenteellisen ohjelmoinnin rakenteita dirty source code restructure code Käytetään aputyökaluja toiminnan ymmärtämiseksi clean source code extract abstractions processing interface Miten nykyinen käyttöliittymä toimii? Mikä on relevanttia jatkossa? initial specification refine & simplify database Tietomäärittelyjen arviointi esim. luokan attribuuttien kannalta. Tietokannan kaavan arviointi. final specification 35

36 30. Ohjelmistoprosessin parantaminen menetelmiä ja malleja kyvykkysmalli CMMI 36

37 Prosessin arviointi ja parantaminen Software Process identifies modifications to is examined by identifies capabilities and risk of Software Process Assessment Software Process Improvement leads to leads to Capability Determination motivates Pressman 2005

38 Ohjelmistoprosessin parantaminen yrityksessä PSP (Personal Software Process) Humphreyn (1996) esittämä menetelmä, joka tavoitteena on henkilökohtaisen osaamisen parantaminen TSP (Team Software Process) Humphreyn (2000) esittämä menetelmä, joka tavoitteena on ryhmätyön parantaminen SW-CMM (Capability Maturity Model) US DoD:n kehittämä malli alihankkijoiden ohjelmistoprosessin arvioimiseksi. Kiinnittää prosessin parannuskohteet viidellä kypsyystasolla (Humphrey 1989). Crosby esitteli tasot jo BOOTSTRAP Eurooppalainen versio SW-CMM mallista. Joustavampi kuin CMM, koska parantaminen voidaan kohdistaa haluttuun osaprosessiin (Kuvaja et al. 1994). Tuki loppui Ilkka Tervonen 38

39 Ohjelmistoprosessin parantaminen... SPICE (Software Process Improvement and Capability Determination) malli = ISO standardi BOOTSTRAPin periaatteiden pohjalle rakennettu standardi ISO 9001 CMM mallin kaltainen malli, jonka avulla varmistutaan alihankkijoiden ohjelmistoprosessin laadusta ISO 9001 sertifikaatti vastaa CMM tasoa 1-3 CMMI (Capability Maturity Model Integration) CMM mallin kehittyneempi versio (V1.1 julkistettiin Tammikuussa 2002) Mallin staged representation osa vastaa CMM mallia Mallin continuous representation osa vastaa SPICE mallia Ilkka Tervonen 39

40 Organisaatiokohtainen prosessin suorituskyky Mittauksiin perustuva projektin hallinta Organisaatiokohtainen innovointi ja käyttöön ottaminen Kausaalinen analyysi ja ratkaisut Vaatimusten kehittäminen Tekninen ratkaisu Tuotteen integrointi Verifiointi ja validointi Organisaatiokohtainen prosessin suuntaaminen Organisaatiokohtainen prosessinmäärittely Organisaatiokohtainen koulutus Integroitu projektin hallinta Integroitu sopimusten hallinta Riskien hallinta... Taso 3: Määritelty (defined) prosessin standardointi Taso 2: Hallittu (managed) projektin hallinta Taso 5: Optimoiva (optimizing) jatkuva parantaminen Taso 4: Määrällisesti hallittu Vaatimusten hallinta Projektin suunnittelu Projektin valvonta Alihankkijoiden sopimusten valvonta Mittaus ja analyysi Laadunvarmistus (prosessi ja tuote) Tuotteenhallinta Taso 1: Suoritettu (performed) CMMI (staged, tasoittainen) kypsyystasot ja prosessialueet

41 Jatkuva (continuous) CMMI malli Kyvykkyystaso PP REQM MA CM PPQA... Prosessialue PP Project planning REQM Requirements management MA Measurement and analysis CM Configuration management PPQA Process and product quality assurance Taso 0: Epätäydellinen prosessialue (esim PP) ei toteuta tason 1 tavoitteita Taso 1: Suoritettu kaikki prosessialueen tavoitteet täytetty Taso 2: Hallittu kaikki tason 1 kriteerit saavutettu lisäksi noudatetaan organisaatiolle määriteltyjä menettelytapoja Taso 3: Määritelty kaikki tason 2 kriteerit saavutettu lisäksi prosessi on räätälöity organisaatiolle Taso 4: Määrällisesti hallittu kaikki tason 3 kriteerit saavutettu lisäksi prosessialuetta parannetaan mittauksin ja arvioinnein Taso 5: Optimoiva kaikki tason 4 kriteerit saavutettu lisäksi prosessialuetta optimoidaan tilastollisin keinoin Ilkka Tervonen 41

42 Jatkuva CMMI malli Jokaiselle prosessialueelle määritellään tavoitteet (specific goals, SG) ja käytänteet (specific practices, SP). Esim. projektin suunnittelu SG 1: Ota käyttöön arvioinnit SP 1.1 arvioi projektin laajuus SP 1.2 arvioi erilliset tehtävät projektissa SP 1.3 määrittele projektin elinjakso SP 1.4 määrittele työpanos- ja kustannusarviot SG 2: Kehitä projektisuunnitelma SP 2.1 tee budjetti ja aikataulu SP 2.2 tunnista projektin riskit SP 2.3 tee suunnitelma tiedon hallinnalle SP 2.4 tee suunnitelma projektin resursseista SP 2.5 tee suunnitelma tarvittavasta tietämyksestä ja taidoista SP 2.6 tee suunnitelma, miten asiakkaat otetaan mukaan SP 2.7 tee projektisuunnitelma SG 3: Hanki sitoutuminen suunnitelmaan Ilkka Tervonen 42

43 Jatkuva CMMI malli CMMI määrittelee myös viisi geneeristä tavoitetta GG (ja niitä vastaavat käytännöt GP), joiden avulla arvioidaan mille kyvykkyystasolle prosessialueessa on päästy GG 1: Toteuta prosessialueen erityiset tavoitteet (SG) GG 2: Vakiinnuta hallittu prosessi GP 2.1 ota käyttöön organisaatiokohtainen menettelytapa GP 2.2 suunnittele prosessi GP 2.3 varaa resurssit GP 2.4 kiinnitä vastuut GP 2.5 kouluta henkilöstö GP 2.6 hallitse tuotteet (konfiguraatiot) GP 2.7 tunnista ja sido prosessiin asiakkaan edustajat GP 2.8 valvo prosessia GP 2.9 arvioi prosessin noudattamista GO 2.10 katselmoi tilanne ylemmän johdon kanssa GG 3: Vakiinnuta määritelty prosessi GG 4: Vakiinnuta määrällisesti hallittu prosessi GG 5: Vakiinnuta optimoiva prosessi Ilkka Tervonen 43

44 ROI (Return on Investment) eri prosessin parantamistavoille David F. Rico 2003 (www.davidfrico.com/rico03apdf.htm) ROI = Ratio of adjusted benefits to costs Benefits - Costs x 100% Costs 40:1 33:1 Benefit/Cost Ratio 30:1 20:1 26:1 23:1 10:1 8:1 3:1 2:1 Inspection PSP TSP SW-CMM ISO 9001 CMMI

45 SEMAT (Software Engineering Methods and Theory) ydin (Asiat (alphat), joita työstetään ohjelmistojen kehittämisen aikana) Ilkka Tervonen Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp

46 Asiat, joita tehdään ohjelmistojen kehittämisen aikana Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp

47 Korttien avulla saadaan kehitys näkyväksi Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp

48 Korttien avulla arvioidaan tiimin/projektin tilanne Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp

49 Mitä seuraavaksi (mitä ei vielä olla tehty)? Jacobson Ivar, Ng Pan-Wei, McMahon Paul, Spence Ian, Lidman Svante, The Essence of Software Engineering: the Semat Kernel CSI Communications, August 2013, pp

50 Soveltuvat lait ja pohdiskelun aiheita 1. Projektiriskit voidaan ratkaista tai niitä voidaan lieventää, kun ne tunnistetaan aikaisessa vaiheessa /hyp_no 17, Boehm 1989 Riskien hallinnan tulee olla luonnollinen osa projektin hallintaa. Spiraalimalli on hyvä esimerkki riskiohjatusta prosessimallista, joka ohjaa riskien tunnistamiseen varhaisessa vaiheessa.

51 Soveltuvat lait ja pohdiskelun aiheita 2. Pienissä muutoksissa on suurempi virhetiheys kuin suurissa muutoksissa / no 30, Basili&Perricone 1984, Möller 1995 Pienen muutoksen tekeminen vaatii laajan kokonaisuuden ymmärtämistä, aivan kuten suurissa muutoksissa. Pienten muutosten suhteellinen kustannus ja virhealttius on korkeampi. Lakia perustellaan esim. oheisella taulukolla (Basili&Perricone) tulosta on perusteltu rajapintavirheiden suurella osuudella ja niiden jakautumisella tasaisesti kaikkiin moduuleihin aineiston vinoudella (vain vähän suuria moduuleja, niitä testattu ehkä paremmin) Moduulin koko (lkm, virheellisten lkm) Kompleksisuus (keskiarvo) Virheitä / KLOC 0-50 (258, 49) (70, 25) (26, 13) (13, 7) > 200 (3, 2)

52 Soveltuvat lait ja pohdiskelun aiheita 3 Kypsät prosessit ja yksilöllinen taito parantaa suunnittelua, kasvattaa tuottavuutta ja vähentää virheitä / no 35, Humphrey 1989 Motorolan esimerkissä CMM 2 tasolla virheitä/kloc 4.4, tuottavuus 1.0 CMM 3 tasolla virheitä/kloc 2.1, tuottavuus 0.8 (syy: peer reviews) CMM 4 tasolla virheitä/kloc 1.0, tuottavuus

53 Soveltuvat lait ja pohdiskelun aiheita Mitkä kahdeksan omiin kokemuksiin perustuvaa, COTS perustaisten järjestelmien ylläpitoon liittyvää oppimaa Reifer et al. oheisessa paperissa esittävät? Buschmann esittelee kahdessa paperissaan kolme arkkitehtuurin hoitamiseen (gardening) ja parantamiseen liittyvää periaatetta, refaktoroinnin (refactoring), uudelleensuunnittelun (reengineering) ja uudelleen kirjoittamisen (rewriting). Kerro, mitä niillä tarkoitetaan ja miten ne pitäisi suorittaa, jos haluaa tehdä ne hyvin. Reifer D., Basili V., Boehm B., Clark B., Eight Lessons Learned during COTS-Based Systems Maintenance, IEEE Software, vol. 20, no. 5, 2003, pp Buschmann F., Gardening Your Architecture, Part 1: Refactoring, IEEE Software, vol 28, no 4, 2011, pp Buschmann F., Gardening Your Architecture, Part 2: Reengineering and Rewriting, IEEE Software, vol 28, no 5, 2011, pp

54 Soveltuvat lait ja pohdiskelun aiheita Jacobson et al. esittelevät Semat periaatteen (Semat ydin & käsitemalli) oheisessa paperissa. Mitä etuja Semat ydin tarjoaa käyttäjälle tekijöiden mukaan? Mitä tarkoitetaan käsitteellä alpha? Miten tiimin tilannetta voidaan arvioida Semat korttien avulla? Jacobson I., Ng P-W, McMahon P., Spence I., Lidman S., The Essence of Software Engineering: the Semat Kernel, document_library/get_file?uuid=8e c46-49b5- a bae237f&

55 Harjoitustehtävät: viikko 9 Asenna Git versionhallintajärjestelmä koneellesi. Asennusohjeita löytyy esim. sivulta ja materiaalista 1. Tutustu Git versionhallintajärjestelmään sivulla olevan esimerkkimateriaalin avulla ja aseta Gitille käyttäjänimesi ja sähköpostiosoite. 2. Ota jonkin hakemistosi tiedostot versionhallintaan, tee johonkin tiedostoon muutoksia ja commitoi (vahvista) ne commit komennolla. 3. Katsele tekemiäsi muutoksia log komennolla. 4. Luo uusi kehityshaara ja tee siellä muutoksia johonkin tiedostoosi ja commitoi ne. 5. Palaa takaisin master haaraan ja tee siellä muutoksia saman nimiseen tiedostoon kuin edellä ja commitoi ne. 6. Yhdistä kehityshaara ja master haara merge komennolla, korjaa tiedoston ristiriitaa aiheuttavat rivit ja commitoi muutokset versionhallintaan. 7. Katsele tekemiäsi muutoksia log komennolla. 8. Nimeä commitoidut versiot komennolla tag siten, että ensimmäinen versio on v1.0 ja viimeinen v2.0 (väliversiolle voit antaa nimet v1.1 jne.). 9. Vertaile versioiden eroja komennolla diff. 55

56 Harjoitustehtävät: viikko 9 Lisätehtävä (ei pakollinen) Jos haluat lisäharjoittelua voit tutustua sivulla esiteltyyn esimerkkiin, kuinka haarautumista voidaan käyttää eri versioiden ja julkaisujen hallintaan. Tee samankaltaista kehitys- ja julkaisuversioiden hallintaa jollekin omalle tiedostolle. 56

57 Harjoitustehtävät: viikko 10 Projektin tavoitteena on kehittää ohjelmisto varastettujen pyörien etsimiselle, joka toimii varastettujen kameratarvikkeiden etsimiskäytännön tapaan. Rahoitus projektille hankitaan joukkorahoituksella (crowdfunding). Tehtävänäsi on suorittaa projektin tilanteen arviointi SEMAT analyysin mukaisesti. Tässä riittää arvioida SEMAT alphat Asiakas (Customer) ja Ratkaisu (Solution) aihealueilla (areas of concern). Tämä tarkoittaa alphoja Mahdollisuus (Opportunity), Sidosryhmät (Stakeholders), Vaatimukset (Requirements) ja Ohjelmisto (Software system). Käytä arvioinnissa arviointipohjaa, joka löytyy tehtäväkuvauksesta (SEMAT esimerkki) kurssisivulta (Noppa) kohdasta Yhteinen lisämateriaali. 57

Harjoitustehtävät: Ohjelmistotekniikka kevät 2015 (harjoitustyöraportin deadline 8.3.2014) (Kalenteri-)Viikko 3:

Harjoitustehtävät: Ohjelmistotekniikka kevät 2015 (harjoitustyöraportin deadline 8.3.2014) (Kalenteri-)Viikko 3: 1 Harjoitustehtävät: Ohjelmistotekniikka kevät 2015 (harjoitustyöraportin deadline 8.3.2014) (Kalenteri-)Viikko 3: 1. Lue paperit McConnell S., and Tripp L., Professional Software Engineering: Fact or

Lisätiedot

Prosessien kehittäminen. Prosessien parantaminen. Eri mallien vertailua. Useita eri malleja. Mitä kehitetään?

Prosessien kehittäminen. Prosessien parantaminen. Eri mallien vertailua. Useita eri malleja. Mitä kehitetään? Prosessien kehittäminen Prosessien parantaminen Sami Kollanus TJTA330 Ohjelmistotuotanto 21.2.2007 Mitä kehitetään? CMMI, SPICE yms. Miten kehittämishanke saadaan toteutettua? Organisaation kehittämisen

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

Harjoitustehtävät: Ohjelmistotekniikka syksy 2015 (harjoitustyöraportin deadline 23.12.2015) Harjoitus 1:

Harjoitustehtävät: Ohjelmistotekniikka syksy 2015 (harjoitustyöraportin deadline 23.12.2015) Harjoitus 1: 1 Harjoitustehtävät: Ohjelmistotekniikka syksy 2015 (harjoitustyöraportin deadline 23.12.2015) Harjoitus 1: 1. Lue paperit McConnell S., and Tripp L., Professional Software Engineering: Fact or Fiction,

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

Joonas Ruotsalainen GIT PIKAOPAS. Tutkielma 2011

Joonas Ruotsalainen GIT PIKAOPAS. Tutkielma 2011 1 Joonas Ruotsalainen GIT PIKAOPAS Tutkielma 2011 2 SISÄLTÖ 1. JOHDANTO... 3 2. ASENTAMINEN... 4 3. KÄYTTÖ... 4 3.1 Perusasetukset... 4 3.2 Git:n ottaminen käyttöön projektissa... 5 3.3 Tiedostojen lisääminen

Lisätiedot

Fujitsu SPICE Lite. Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat. Copyright 2010 FUJITSU

Fujitsu SPICE Lite. Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat. Copyright 2010 FUJITSU Fujitsu SPICE Lite Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat Copyright 2010 FUJITSU Laatu ja prosessit Fujitsussa Laatujärjestelmän rakentaminen ja systemaattinen prosessijohtaminen

Lisätiedot

Ohjelmistoprojektien hallinta Vaihejakomallit

Ohjelmistoprojektien hallinta Vaihejakomallit Ohjelmistoprojektien hallinta Vaihejakomallit Vaihejakomallit TAVOITE: YMMÄRTÄÄ eri vaihejakomallien etujajahaittoja 2 Erilaisia malleja Tee ja korjaa (Code-and-Fix) Vesiputousmalli (Waterfall) Vesiputousmalli

Lisätiedot

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011 LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011 TEHTÄVÄ Määrittele laatu Mitä riskien hallintaan kuuluu? Jouni Huotari & Esa Salmikangas 2 LAATU JA LAADUNVARMISTUS

Lisätiedot

Prosessikuvaukset ja elinkaarimallit

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

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY

SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY Anna-Liisa Koskinen SISÄLTÖ Uusi rakenne Uusia määritelmiä Keskeisistä muutoksista 2 ISO 14001 ympäristöjohtamisjärjestelmä ISO 14001 on tunnettu

Lisätiedot

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

ITK130 Ohjelmistojen luonne

ITK130 Ohjelmistojen luonne ITK130 Ohjelmistojen luonne Luennon sisältö Ohjelmistotekniikka ja vaatimukset Ohjelmistotuote Ei-toiminnallisten vaatimusten luokittelu Sisäiset ja ulkoiset vaatimukset Oikeellisuus Luotettavuus Kestävyys

Lisätiedot

Onnistunut ohjelmistoprojekti

Onnistunut ohjelmistoprojekti Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden

Lisätiedot

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Arkkitehtuuritietoisku eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Esikysymys Kuinka moni aikoo suunnitella projektityönsä arkkitehtuurin? Onko tämä arkkitehtuuria?

Lisätiedot

Tietohallinnon liiketoimintalähtöinen toiminnanohjaus IT-ERP

Tietohallinnon liiketoimintalähtöinen toiminnanohjaus IT-ERP Tietohallinnon liiketoimintalähtöinen toiminnanohjaus IT-ERP 27.9.2007 Juha Berghäll Efecte Oy juha.berghall@efecte.fi / +358 40 589 5121 Kuka puhuu? z Juha Berghäll z Country Manager Finland z Laaja kokemus

Lisätiedot

Prosessien kehittäminen osa 2. Prosessien kehittämisen haasteita. SEI:n mukan kolme odotettavissa olevaa ongelmaa

Prosessien kehittäminen osa 2. Prosessien kehittämisen haasteita. SEI:n mukan kolme odotettavissa olevaa ongelmaa SEI:n mukan kolme odotettavissa olevaa ongelmaa Prosessien kehittäminen osa 2 Sami Kollanus TJTA330 Ohjelmistotuotanto 27.2.2007 Tämä ei sovellu meille Resurssit valuvat prosessien kehittämisestä tärkeämpiin

Lisätiedot

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS

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

Millainen on onnistunut ICT-projekti?

Millainen on onnistunut ICT-projekti? Millainen on onnistunut ICT-projekti? Ohjelmistotuotannon lehtori Tero Tensu Ahtee Ohjelmistotekniikan laitoksella 1990- Projektityö-kurssilla 1991- pesunkestävä yliopistohampuusi ei päivääkään oikeissa

Lisätiedot

Tietojärjestelmän osat

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

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Teollisuusautomaation tietoturvaseminaari Purchasing Manager, Hydro Lead Buyer, Industrial Control Systems 1 Agenda / esityksen tavoite

Lisätiedot

Mitä on ohjelmistotuotanto? Johdanto. Tämän kurssin näkökulma. Kurssin suhde muuhun opetukseen

Mitä on ohjelmistotuotanto? Johdanto. Tämän kurssin näkökulma. Kurssin suhde muuhun opetukseen Mitä on ohjelmistotuotanto? Johdanto Sami Kollanus TJTA330 Ohjelmistotuotanto 9.1.2007 Ohjelmistotekniikka (Software Engineering) tarkoittaa pätevien insinööriperiaatteiden vakiinnuttamista ja käyttämistä

Lisätiedot

3. Projektinhallinta. Miksi ohjelmistoprojektin hallinta on erilaista?

3. Projektinhallinta. Miksi ohjelmistoprojektin hallinta on erilaista? 3. Projektinhallinta Ohjelmistoprojektien koon kasvaessa on törmätty projektinhallinnan ongelmiin, kuten jatkuva, osin huonosti hallittu kasvu, myöhästymiset, huono laatu, budjettien ylitykset, projektien

Lisätiedot

HITSAUKSEN TUOTTAVUUSRATKAISUT

HITSAUKSEN TUOTTAVUUSRATKAISUT Kemppi ARC YOU GET WHAT YOU MEASURE OR BE CAREFUL WHAT YOU WISH FOR HITSAUKSEN TUOTTAVUUSRATKAISUT Puolitetaan hitsauskustannukset seminaari 9.4.2008 Mikko Veikkolainen, Ratkaisuliiketoimintapäällikkö

Lisätiedot

Miten voin selvittää säästömahdollisuuteni ja pääsen hyötymään niistä?

Miten voin selvittää säästömahdollisuuteni ja pääsen hyötymään niistä? Se edullisempi tietokanta Miten voin selvittää säästömahdollisuuteni ja pääsen hyötymään niistä? Rasmus Johansson rasmus.johansson@microsoft.com Ratkaisumyyntipäällikkö (Sovellusalusta) Microsoft Oy Miten

Lisätiedot

Tapahtuipa Testaajalle...

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

Laatu tietojärjestelmähankkeissa. Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia

Laatu tietojärjestelmähankkeissa. Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia Laatu tietojärjestelmähankkeissa Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia 5.10.2010 Pohdintaa tietojärjestelmien laadusta Mitä on laatu Miten laatua tavoitellaan tietojärjestelmäprojekteissa

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

Lisätiedot

Ketterä vaatimustenhallinta

Ketterä vaatimustenhallinta Ketterä vaatimustenhallinta ja miksi se on useimmiten hyvä asia K A R I A L HO C E O I M P R OV EIT OY Sisältö ImproveIt Oy Perinteinen vaatimushallinta Ketterä vaatimustenhallinta Monenlaista softakehitystä

Lisätiedot

7. Product-line architectures

7. Product-line architectures 7. Product-line architectures 7.1 Introduction 7.2 Product-line basics 7.3 Layered style for product-lines 7.4 Variability management 7.5 Benefits and problems with product-lines 1 Short history of software

Lisätiedot

Riskienhallinnan perusteet

Riskienhallinnan perusteet Riskienhallinnan perusteet VTT Automaatio Turun kauppakorkeakoulu Työterveyslaitos Tampereen teknillinen korkeakoulu 1(20) Kalvoluettelo Riski -sanasta 3 Riskienhallinta -sanasta 4 Riskienhallinnan perusteet

Lisätiedot

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta OHJ-3010 Ohjelmistotuotannon perusteet Ohjelmistoprojektin hallinta 1 Sisältö Projektiorganisaatio ja sidosryhmät Ohjelmistoprojektin kulku Projektin suunnittelu Ositus Osallistujat Työmäärän arviointi

Lisätiedot

T 76.115 Tietojenkäsittelyopin ohjelmatyö Hirviöryhmä loppukatselmointi. Hirviö. Projektikatselmointi

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

ISO 21500 Päivi Kähönen-Anttila 24.9.2014

ISO 21500 Päivi Kähönen-Anttila 24.9.2014 ISO 21500 Päivi Kähönen-Anttila 24.9.2014 SISÄLTÖ Projektinhallinnan standardeja Kypsyysmallien ja projektinhallintastandardien historia ISO 21500 standardi ISO 21500 standardin hyötyjä ISO 21500 prosessi

Lisätiedot

Tietojenkäsittelytieteiden koulutusohjelma. Tietojenkäsittelytieteiden laitos Department of Information Processing Science

Tietojenkäsittelytieteiden koulutusohjelma. Tietojenkäsittelytieteiden laitos Department of Information Processing Science Tietojenkäsittelytieteiden koulutusohjelma Tietojenkäsittelytieteet Laskennallinen data-analyysi Ohjelmistotekniikka, käyttöjärjestelmät, ihminen-kone -vuorovaikutus Teoreettinen tietojenkäsittelytiede

Lisätiedot

Ohjelmistotuotanto historiallinen perspektiivi. 25.11.2013 JOTU2013/K.Systä 1

Ohjelmistotuotanto historiallinen perspektiivi. 25.11.2013 JOTU2013/K.Systä 1 Ohjelmistotuotanto historiallinen perspektiivi 25.11.2013 JOTU2013/K.Systä 1 Alustava luentoaikataulu 26.8: Johdanto + historiaa, mitä on ohjelmistotuotanto 2.9: Ohjelmistojen roolista ja ohjelmistotyön

Lisätiedot

Nimi: Opnro: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä. 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla:

Nimi: Opnro: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä. 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla: a) käytettävyys b) käyttäjäkeskeinen suunnittelu c) luonnollinen kieli

Lisätiedot

Web Services tietokantaohjelmoinnin perusteet

Web Services tietokantaohjelmoinnin perusteet ASP.NET Web Services Web Services tietokantaohjelmoinnin 2 (22) Sisällys Harjoitus 1: Tietokannat ja Web Services... 3 Harjoitus 2: Windows Client... 10 Harjoitus 3: Datan päivitys TableAdapterin avulla...

Lisätiedot

Projektinhallintapäivä 22.8.2007, Tampere Poimintoja koulutusnäkökulmasta

Projektinhallintapäivä 22.8.2007, Tampere Poimintoja koulutusnäkökulmasta Liiketoiminta kehittyy kehity sinäkin. Projektinhallintapäivä 22.8.2007, Tampere Poimintoja koulutusnäkökulmasta Päivi Hietanen, johtaja paivi.hietanen@tieturi.fi HTC Santa Maria, Tammasaarenkatu 5, 00180

Lisätiedot

Portaaliteknologiat mahdollistavat ajattelutavan muutoksen

Portaaliteknologiat mahdollistavat ajattelutavan muutoksen - 1 - Portaaliteknologiat mahdollistavat ajattelutavan muutoksen Petri Kanerva Fusion Middleware Architect, Oracle Finland Oy 29.04.2010 The following is intended to outline our general

Lisätiedot

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS 28.9.2009

LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS 28.9.2009 LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS 28.9.2009 TEHTÄVÄ Määrittele laatu Mihin laadunvarmistus tähtää? Mitä riskien hallintaan kuuluu? Jouni Huotari & Esa Salmikangas

Lisätiedot

Security server v6 installation requirements

Security server v6 installation requirements CSC Security server v6 installation requirements Security server version 6.4-0-201505291153 Pekka Muhonen 8/12/2015 Date Version Description 18.12.2014 0.1 Initial version 10.02.2015 0.2 Major changes

Lisätiedot

Vaatimustenhallinta. Exit

Vaatimustenhallinta. Exit Vaatimustenhallinta Asiakasvaatimusten hallinnan tarkoitus on analysoida ja priorisoida kerätyt asiakasvaatimukset sekä hallita niitä ohjelmistokehityksen eri vaiheissa. Olennaista on jäljitettävyys: on

Lisätiedot

Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara

Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara Mitä? Mitä? Yrityksen sisäinen Mitä? Yrityksen sisäinen Alihankinta Mitä? Yrityksen sisäinen Open Source -kehitys Alihankinta

Lisätiedot

Tietohallinnon arvo liiketoiminnalle

Tietohallinnon arvo liiketoiminnalle Tietohallinnon arvo liiketoiminnalle Viikko-seminaari 27.9.2007 Lauri Byckling, Deloitte Mitä on arvo Arvon määritelmiä: Hyöty suhteessa hintaan Laatu suhteessa odotuksiin Saatu lisähyöty Tietohallinnon

Lisätiedot

Tietoturvallisuus yhteiskunnan, yritysten ja yksityishenkilöiden kannalta

Tietoturvallisuus yhteiskunnan, yritysten ja yksityishenkilöiden kannalta Tietoturvallisuus yhteiskunnan, yritysten ja yksityishenkilöiden kannalta Sähköurakoitsijapäivät 21.11.2013 Kari Wirman 7.11.2013 Kari Wirman 21.11.2013 Kari Wirman, ICT-pooli Tieto Tieto on nyky-yhteiskunnan

Lisätiedot

Jyrki Kontio, Ph.D. 11.3.2010

Jyrki Kontio, Ph.D. 11.3.2010 Jyrki Kontio, Ph.D. Principal Consultant, R & D-Ware Oy Risk mgmt consulting and training Software engineering consulting Technical due diligence Process management and improvement Board member at QPR

Lisätiedot

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Sisältö Mistä tietoja koottu? Opit Yhteenveto Mistä tietoja koottu? Nämä tiedot on kerätty

Lisätiedot

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

Ohjelmistotekniikka - 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 Luku 3:

Lisätiedot

Tietojärjestelmä uusiksi? Toimijaverkostot, niiden haasteet ja ratkaisut

Tietojärjestelmä uusiksi? Toimijaverkostot, niiden haasteet ja ratkaisut Tietojärjestelmä uusiksi? Toimijaverkostot, niiden haasteet ja ratkaisut Samuli Pekkola Aki Alanne Taru Salmimaa Novi Research Center Tampereen teknillinen yliopisto Sisältö tausta, motiivi ja konteksti

Lisätiedot

Keskitetyn integraatiotoiminnon hyödyt

Keskitetyn integraatiotoiminnon hyödyt Keskitetyn integraatiotoiminnon hyödyt Janne Kangasluoma / Chief Enterprise Architect, Ilmarinen Teemu O. Virtanen / Director, Information Logistics, Digia 2013 IBM Corporation HUOLEHDIMME NOIN 900 000

Lisätiedot

Tietomallipohjainen liiketoiminta RYM-SHOK 2.10.2009 Tietomallipohjaisten prosessien haasteet ja mahdollisuudet omistajille

Tietomallipohjainen liiketoiminta RYM-SHOK 2.10.2009 Tietomallipohjaisten prosessien haasteet ja mahdollisuudet omistajille Jukka Riikonen Tietomallipohjainen liiketoiminta RYM-SHOK 2.10.2009 Tietomallipohjaisten prosessien haasteet ja mahdollisuudet omistajille Viiteympäristö Rakennusinvestoinnit joista yli 1 M :n hankkeisiin

Lisätiedot

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa 13.05.2015 Terveydenhuollon ATK-päivät Tampere-talo Yleistä Riskienhallintaan löytyy viitekehyksiä/standardeja kuten ISO 31000

Lisätiedot

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt. Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.fi Avoimen tuotteenhallinta Esityksen sisältö Mitä on tuotteenhallinta?

Lisätiedot

Master s Thesis opinnäytetyön tuki Industrial Management Master s -ohjelmassa. TkT Marjatta Huhta, Metropolia

Master s Thesis opinnäytetyön tuki Industrial Management Master s -ohjelmassa. TkT Marjatta Huhta, Metropolia Master s Thesis opinnäytetyön tuki Industrial Management Master s -ohjelmassa TkT Marjatta Huhta, Metropolia 1 Esityksen sisältö Master s in Industrial Management ohjelman kokonaisuus, tavoitteet ja rakenne

Lisätiedot

T-110.5690 Yritysturvallisuuden seminaari. Kappaleet 15-16: Operational Risk Management Assurance Management

T-110.5690 Yritysturvallisuuden seminaari. Kappaleet 15-16: Operational Risk Management Assurance Management T-110.5690 Yritysturvallisuuden seminaari Kappaleet 15-16: Operational Risk Management Assurance Management Operational Risk Management Määritelmä Lakien tuomat vaatimukset Laadulliset ja numeraaliset

Lisätiedot

tsoft tsoftin prosessien parantamistoiminta: Johdanto ohjelmistoprosessien arviointiin Agenda Ilmari Saastamoinen, 15.9.2004, Joensuun yliopisto

tsoft tsoftin prosessien parantamistoiminta: Johdanto ohjelmistoprosessien arviointiin Agenda Ilmari Saastamoinen, 15.9.2004, Joensuun yliopisto tsoftin prosessien parantamistoiminta: Johdanto ohjelmistoprosessien arviointiin tsoft Ilmari Saastamoinen, 15.9.2004, Joensuun yliopisto 16.9.2004 1 Agenda Ohjelmistoprosessien arviointi Arviointi- ja

Lisätiedot

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen

KONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi

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

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Opinnäytetyö KESKI-POHJANMAAN AMMATTIKORKEAKOULU Puutekniikan koulutusohjelma Toukokuu 2009 TIIVISTELMÄ OPINNÄYTETYÖSTÄ Yksikkö Aika Ylivieska

Lisätiedot

Elinkaaren huomioiva hankintaprosessi ja elinkaarenaikainen kustannus-hyöty analyysi. Jyri Hanski, VTT Turvallisuus 2012 -messut 5.9.

Elinkaaren huomioiva hankintaprosessi ja elinkaarenaikainen kustannus-hyöty analyysi. Jyri Hanski, VTT Turvallisuus 2012 -messut 5.9. Elinkaaren huomioiva hankintaprosessi ja elinkaarenaikainen kustannus-hyöty analyysi Jyri Hanski, VTT Turvallisuus 2012 -messut 5.9.2012 Hankinnan ongelmakohdat Tekninen osaaminen hankinnasta yleensä hyvällä

Lisätiedot

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy www.softqa.fi

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy www.softqa.fi Laadukas vaatimustenhallinta Pekka Mäkinen www.softqa.fi Esityksen perusajatuksia Vaatimuksilla on elinkaari ja ne muuttuvat. Tuotteen elinkaari vaikuttaa vaatimuksiin. Vaatimusten keruussa ja -hallinnassa

Lisätiedot

PALVELUKULTTUURIN JA MINDSETIN KEHITTÄMINEN 3 STEP IT. 15.3.2013 2013 3 Step IT Group / Palvelukulttuuri / Artti Aurasmaa

PALVELUKULTTUURIN JA MINDSETIN KEHITTÄMINEN 3 STEP IT. 15.3.2013 2013 3 Step IT Group / Palvelukulttuuri / Artti Aurasmaa PALVELUKULTTUURIN JA MINDSETIN KEHITTÄMINEN 3 STEP IT 1 Päivän kolme kysymystä Miksi, miten mitä? Mitä? Miten? Mitä? 1. 3 Step IT 3 minuutissa 2. Työntekijät ensin 3. Arvoista asenteeseen 4. PPPP -> SAVE

Lisätiedot

Yhdeksän mittaria ohjelmistotuotannon. seuraamiseen. tsoft. Vesa Tenhunen Joensuun yliopisto, TKT:n laitos 15.9.2004. http://cs.joensuu.

Yhdeksän mittaria ohjelmistotuotannon. seuraamiseen. tsoft. Vesa Tenhunen Joensuun yliopisto, TKT:n laitos 15.9.2004. http://cs.joensuu. Yhdeksän mittaria ohjelmistotuotannon tilan seuraamiseen tsoft Vesa Tenhunen Joensuun yliopisto, TKT:n laitos 15.9.2004 http://cs.joensuu.fi/tsoft/ Yhdeksän mittaria ohjelmistotuotannon tilan seuraamiseen

Lisätiedot

Finpro Foresight. Toimitusjohtaja Kari Häyrinen Finpro ry 9-11-2010

Finpro Foresight. Toimitusjohtaja Kari Häyrinen Finpro ry 9-11-2010 Finpro Foresight Toimitusjohtaja Kari Häyrinen Finpro ry 9-11-2010 Finpron Missio Rakentamassa kansainvälisesti menestyvää Suomea Strategy 2010-2012 / Finpro ry 2 Finpron toiminnan perusta Kilpailukykyä

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

Konesali ilman rajoja Kongressi A 5.3.2013

Konesali ilman rajoja Kongressi A 5.3.2013 Konesali ilman rajoja Kongressi A 5.3.2013 t SC Orchestrator 2012 SP1 Harri Puupponen 5.3.2013 t 2012 Microsoft Corporation. All rights reserved. Sisältö Yleistä Arkkitehtuuri Uudet ominaisuudet Demoja

Lisätiedot

Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.

Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9. Käytettävyyslaatumallin rakentaminen web-sivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.2005 Kirjoittajan ABC-kortti

Lisätiedot

Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu?

Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu? Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu? Laatupäällikkö Anna-Maija Haapala osastonylilääkäri, dosentti Fimlab Laboratoriot Oy STANDARDI 15189 (2012) Suomennos standardista

Lisätiedot

Miten johdan huolto- ja korjaamotoimintaa laadukkaasti? Autokauppa 2015 6.11.2014 Finlandiatalo

Miten johdan huolto- ja korjaamotoimintaa laadukkaasti? Autokauppa 2015 6.11.2014 Finlandiatalo Miten johdan huolto- ja korjaamotoimintaa laadukkaasti? Autokauppa 2015 6.11.2014 Finlandiatalo Keijo Mäenpää Liikkeenjohdon konsultti Diplomi-insinööri Tavoitteena Sujuvasti toimiva kyvykäs organisaatio

Lisätiedot

Projektin suunnittelu. CMMI-käytänteet. Projektin suunnittelu CMMI-käytänteet

Projektin suunnittelu. CMMI-käytänteet. Projektin suunnittelu CMMI-käytänteet Projektin suunnittelu CMMI-käytänteet Projektin suunnittelu Sami Kollanus TJTA330 Ohjelmistotuotanto 17.1.2007 Laaditaan estimaatit: Määritellään projektin laajuus (scope) Määritellään tehtävien ja tuotosten

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet Järjestelmäarkkitehtuuri (TK081702) Integraation tavoitteita Lähtökohta Web-palvelut Asiakasrekisteri ERP, Tuotannon ohjaus Tuotanto Myynti Intranet Extranet? CRM Johdon tuki Henkilöstö Kirjanpito Palkanlaskenta

Lisätiedot

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Mikä on IT arkkitehtuuri? Liiketoimintamalli määrittelee IT arkkitehtuurin IT arkkitehtuuri ottaa kantaa sovelluksen laadullisiin vaatimuksiin

Lisätiedot

1. Johdanto. Ohjelmistotuotannon ongelmia

1. Johdanto. Ohjelmistotuotannon ongelmia 1. Johdanto Mitä ohjelmistotuotanto on? ohjelmointi + ohjelmisto + tekniikat + insinööritaito + kurinalainen työskentely Määritelmä (60-luvun ohjelmistokriisi): The establishment and use of sound principles

Lisätiedot

Tavoitekeskeinen ylläpidon mittaaminen asiakastyytyväisyyden parantamisessa

Tavoitekeskeinen ylläpidon mittaaminen asiakastyytyväisyyden parantamisessa Tavoitekeskeinen ylläpidon mittaaminen asiakastyytyväisyyden parantamisessa Henna Vallin 19.6.2007 Tietojenkäsittelytieteen laitos Joensuun yliopisto Pro gradu -tutkielma Sisältö TIIVISTELMÄ 1 1 JOHDANTO

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

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

PCI DSS 3.0. Merkittävimmät muutokset Seppo Heikkinen, QSA seppo.heikkinen@nixu.com. 15.1.2014 Nixu 2014 1

PCI DSS 3.0. Merkittävimmät muutokset Seppo Heikkinen, QSA seppo.heikkinen@nixu.com. 15.1.2014 Nixu 2014 1 PCI DSS 3.0 Merkittävimmät muutokset Seppo Heikkinen, QSA seppo.heikkinen@nixu.com 15.1.2014 Nixu 2014 1 Yleistä PCI DSS standardin kehittämisestä PCI SSC (Payment Card Industry Security Standards Council)

Lisätiedot

Elinar Oy Ltd IBM Arkistointiratkaisut

Elinar Oy Ltd IBM Arkistointiratkaisut Löydä nautittavat ratkaisut Elinar Oy Ltd IBM Arkistointiratkaisut 16.11.2009 Elinar Oy Ltd Monipuolinen osaaminen: Asiakkaan tarpeen analysointi ja ongelmien tehokas ratkaisu mm. IBM Content tuoteperhe,

Lisätiedot

Työkalut ohjelmistokehityksen tukena

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

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina - Käytännön esimerkkejä ITIL ja ITSM mukaisista IT palveluhallinnan toteutuksista ja mahdollisuuksista Ville Koskinen Sales Specialist, HP Software

Lisätiedot

T-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä

Lisätiedot

WEBINAARIN ISÄNNÄT. Jarno Wuorisalo Cuutio.fi. Petri Mertanen Superanalytics.fi. Tomi Grönfors Brandfors.com

WEBINAARIN ISÄNNÄT. Jarno Wuorisalo Cuutio.fi. Petri Mertanen Superanalytics.fi. Tomi Grönfors Brandfors.com WEBINAARI 3.11.2015 Mitä Tag Management on käytännössä ja miten se vaikuttaa analytiikkaan? Petri Mertanen, Super Analytics - @mertanen Jarno Wuorisalo, Cuutio - @jarnowu Tomi Grönfors, Brandfors - @groenforsmethod

Lisätiedot

- Yleistä. - EA ad-hoc group - FINAS S21/2002. - Keskustelua

- Yleistä. - EA ad-hoc group - FINAS S21/2002. - Keskustelua 7,(727(.1,,.$1$59,2,17, 26$1$/$%25$725,21 $..5(',72,17,$ 0LWWDWHNQLLNDQNHVNXV ),1$6 5LVWR6XRPLQHQ 6,6b/7g - Yleistä - EA ad-hoc group - FINAS S21/2002 - Keskustelua

Lisätiedot

Pyhä ITIL - mikä toimii ja mikä ei. Aale Roos www.pohjoisviitta.fi @aalem

Pyhä ITIL - mikä toimii ja mikä ei. Aale Roos www.pohjoisviitta.fi @aalem Pyhä ITIL - mikä toimii ja mikä ei Aale Roos www.pohjoisviitta.fi @aalem ITILIN lyhyt historia 1980 luku brittiläinen julkishallinto sisäinen => mainframe => luokkayhteiskunta => byrokratia => ei asiakkuuksia

Lisätiedot

Tuotekehitys palveluna

Tuotekehitys palveluna Kumppani joka tukee menestystäsi Tuotekehitys palveluna Tekniikka 2010, Jyväskylä Ville Volanen Koko tuotekehitysprojekti samasta paikasta Protoshop tarjoaa tuotekehitystä yhdistettynä tuotteen kaupallistamiseen,

Lisätiedot

Lyhyt johdatus ketterään testaukseen

Lyhyt johdatus ketterään testaukseen TTY:n Testauspäivät, Tampere 15.8.2006 Lyhyt johdatus ketterään testaukseen eli Ketterän ohjelmistokehityksen laatukäytäntöjä Juha Itkonen SoberIT Teknillinen korkeakoulu Juha.Itkonen@tkk.fi Ketterä ohjelmistokehitys

Lisätiedot

SataSPIN. Prosessien parantaminen verkostoitumalla. Porin korkeakouluyksikkö, TTKK

SataSPIN. Prosessien parantaminen verkostoitumalla. Porin korkeakouluyksikkö, TTKK SataSPIN Prosessien parantaminen verkostoitumalla Porin korkeakouluyksikkö, TTKK Ohjelmistoasiantuntemuksen keskus Centre of Software Expertise - CoSE Timo.Varkoi@pori.tut.fi http://www.pori.tut.fi SPI

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

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

SaaS-palvelutoimittajan valinta kilpailukyvyn ja kustannustehokkuuden parantamiseksi. Ari-Pekka Syvänne, Xenetic Oy / HCM-seminaari, 26.3.

SaaS-palvelutoimittajan valinta kilpailukyvyn ja kustannustehokkuuden parantamiseksi. Ari-Pekka Syvänne, Xenetic Oy / HCM-seminaari, 26.3. SaaS-palvelutoimittajan valinta kilpailukyvyn ja kustannustehokkuuden parantamiseksi Ari-Pekka Syvänne, Xenetic Oy / HCM-seminaari, 26.3.2009 Xenetic Xenetic on asiantuntijaorganisaatio, joka tarjoaa asiakkailleen

Lisätiedot

Tietoisku ISO 14001:n ja OHSAS 18001:n tulevista muutoksista. Tuulikki Lammi Versio1,0 2014-09-03

Tietoisku ISO 14001:n ja OHSAS 18001:n tulevista muutoksista. Tuulikki Lammi Versio1,0 2014-09-03 Tietoisku ISO 14001:n ja OHSAS 18001:n tulevista muutoksista Tuulikki Lammi Versio1,0 2014-09-03 Uutta Yhteinen rakenne Rakenne ja termit ovat harmonisoitu Uusitut ISO 14001 ja ISO 45001 tulevat olemaan

Lisätiedot

Testaus teoriassa ja käytännössä. Jukka Paakki Helsingin yliopisto Tietojenkäsittelytieteen laitos

Testaus teoriassa ja käytännössä. Jukka Paakki Helsingin yliopisto Tietojenkäsittelytieteen laitos Testaus teoriassa ja käytännössä Jukka Paakki Helsingin yliopisto Tietojenkäsittelytieteen laitos Teoria = tutkimus IEEE Transactions on Software Engineering, 2000-2002 Software Testing, Verification &

Lisätiedot

SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti

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

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa 1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä

Lisätiedot

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

Lisätiedot

Tarua vai totta: sähkön vähittäismarkkina ei toimi? 11.2.2015 Satu Viljainen Professori, sähkömarkkinat

Tarua vai totta: sähkön vähittäismarkkina ei toimi? 11.2.2015 Satu Viljainen Professori, sähkömarkkinat Tarua vai totta: sähkön vähittäismarkkina ei toimi? 11.2.2015 Satu Viljainen Professori, sähkömarkkinat Esityksen sisältö: 1. EU:n energiapolitiikka on se, joka ei toimi 2. Mihin perustuu väite, etteivät

Lisätiedot

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011 AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä

Lisätiedot