Ohjelmistotekniikka - Luento 6
|
|
- Minna Koskinen
- 5 vuotta sitten
- Katselukertoja:
Transkriptio
1 Ohjelmistotekniikka - Luento 6 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 28. Projektin riskien hallinta Mikä voi mennä pieleen? Millä todennäköisyydellä? Miten pahasti? Miten siitä selvitään?!3
4 Mitä riskillä tarkoitetaan? From Middle French risque, from Italian risco ("risk"; > Modern Italian rischio) and rischiare ("to run into danger"). Latin resicum ( that which cuts, rock, crag ), from Latin resecō ( cut off, loose, curtail, verb), in the sense of that which is a danger to boating or shipping; or from Ancient Greek ῥιζικόν (rhizikón, root, radical, hazard ). Ancient Greek ῥίζα (rhíza, cliff ) due to the hazards of sailing along rocky coasts. From Byzantine Greek ῥιζικό, ριζικό (rhizikó, rizikó, sustenance obtained by a soldier through his own initiative, fortune ), from Arabic ر ز ق (rizq, sustenance, that which God allots ), from Classical Syriac ration ), (rezqā, rōzīqā, daily ܪܘܙܝܩܐ,ܪܙܩܐ 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!4
5 Negatiivinen / positiivinen Negatiivinen riski 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!5
6 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: !6
7 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!7
8 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!8
9 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!9
10 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 Vaikutus- analyysi RE = P * C Riskien määrittely Suositeltu valvonta Tulosten dokumentointi Stoneburner, Goguen, Feringa, Risk Management Guide for Information Technology Systems, 2002!10
11 Riskiin varautuminen Riskiin (riskin laukeamiseen) varautuminen RE (risk exposure) määritellään kaavalla [Hall 1998]: missä RE = P x C P todennäköisyys riskin laukeamisesta C kustannus projektille riskin lauetessa.!11
12 Riskiin varautumisen aste (risk exposure) Kustannus Todennäköisyys Pieni Keskisuuri Korkea Pieni Pieni Pieni Keskisuuri Keskisuuri Pieni Keskisuuri Suuri Suuri Keskisuuri Suuri Suuri!12
13 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
14 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.
15 11 tärkeintä ohjelmistoprojektin riskitekijää Keil M., Cule P., Lyytinen K., Schmidt R., Communications of the ACM, no 11,1998!15
16 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?!16
17 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?!17
18 Riskien luokittelu / U.S. Air suorituskykyriski Force 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.!18
19 Riskien välttäminen, valvonta ja hallinta mitigation (Risk Mitigation, Monitoring and Management) kuinka riskejä voidaan välttää? monitoring mitä tekijöitä seuraamalla voidaan ennustaa riskien laukeamista? management millaisia varasuunnitelmia on, jos riskit toteutuvat?!19
20 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 % Luokittelu PS = Project size risk BU = Business risk FU = Funding risk TE = Technical risk Vaikutus 4 = katastrofaalinen 3 = kriittinen 2 = pieni 1 = vähäinen!20
21 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 riskin vähentämistoimista> > Milloin: < milloin viimeistään vähentämistoimet täytyy tehdä!21
22 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.!22
23 29. Ylläpito ja uudelleensuunnittelu ylläpito ja Lehmanin lait liiketoimintaprosessin ja ohjelmiston uudelleensuunnittelu takaisinmallintaminen/käänteistekniikka!23
24 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)!24
25 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!25
26 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!26
27 Esimerkki elinkaarikustannusten jakautumisesta (Schach 2005) 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 %) vaat.määr. määrittely suun koodaus mod.test integrointi ylläpito % ylläpitotyöstä kuluu ylläpidettävän järjestelmän ymmärtämiseen 27
28 Ylläpidon työpanos koko ohjelmiston elinaikana Korjaava ylläpito 100 % 90 % 80 % Mukauttava ylläpito Täydellistävä ylläpito 70 % 60 % 50 % 40 % 30 % 20 % 10 % Ajankohta, kun täydellistävä vie 65 %, korjaava 17 % ja mukauttava 18 %? aika Wiederholdin (2006) esitystä mukaellen
29 Uudelleensuunnittelu Liiketoiminta prosessit Tieto- järjestelmät Uudelleensuunnittelu Ohjelmisto- sovellukset!29
30 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 Prosessin tunnistus Protoilu Tuotetaan käyttö- tapaukset uudelleen- suunniteltaville prosesseille, Niiden avulla suunnitellaan uudet tehtävät. Prosessin arviointi Tunnistetaan prosessin tehtävät ja niiden kustannukset ja ajantarpeet. Tunnistetaan laatu- ja suorituskykyongelmat. Prosessin määrittely ja suunnittelu Business Process Reengineering (BPR)!30
31 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 uudelleenmuotoilu eteenpäin suunnittelu uudelleenkoodaus inventointi uudelleendokumentointi takaisinmallintaminen Arvioidaan kaikki sovellukset - tarpeellisuus - ylläpidettävyys (katso kuvaus) kuinka paljon, kuinka täydellisesti Ohjelmasta tuotetaan suunnittelutason kuvaus (katso kuvaus)!31
32 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äpito- toimet riittävät Liiketoiminnan arvo Arvokas yritykselle & Laadultaan huono Ei tärkeä yritykselle & Laadultaan huono Arvokas yritykselle & Laadultaan hyvä Ei tärkeä yritykselle & Laadultaan hyvä Niin kauan kun tavalliset ylläpitotoimet riittävät, kannattaa pitää käytössä Järjestelmän laatu Laadultaan huonoa järjestelmää & yritykselle arvotonta ei kannata pitää toiminnassa Sommerville 2004!32
33 Takaisinmallintaminen / käänteistekniikka (reverse engineering) vain rakenteellisen ohjelmoinnin rakenteita Käytetään aputyökaluja toiminnan ymmärtämiseksi Miten nykyinen käyttöliittymä toimii? Mikä on relevanttia jatkossa? Tietomäärittelyjen arviointi esim. luokan attribuuttien kannalta. Tietokannan kaavan arviointi.!33
34 30. Ohjelmistoprosessin parantaminen menetelmiä ja malleja kyvykkysmalli CMMI!34
35 Prosessin arviointi ja parantaminen Pressman 2005!35
36 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 2004.!36
37 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!37
38 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 5: Optimoiva (optimizing) jatkuva parantaminen Taso 4: Määrällisesti hallittu Taso 3: Määritelty (defined) prosessin standardointi Taso 2: Hallittu (managed) projektin hallinta 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!38
39 Jatkuva (continuous) CMMI malli Taso 0: Epätäydellinen 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 prosessialue (esim PP) ei toteuta tason 1 tavoitteita 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 39
40 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!40
41 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!41
42 ROI (Return on Investment) eri prosessin parantamistavoille David F. Rico 2003 ( ROI = Ratio of adjusted benefits to costs Benefits - Costs Costs x 100% 40:1 33:1 30:1 Benefit/Cost Ratio 20:1 10:1 26:1 23:1 8:1 3:1 2:1 Inspection PSP TSP SW-CMM ISO 9001 CMMI!42
43 SEMAT (Software Engineering Methods and Theory) ydin (Asiat (alphat), joita työstetää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. 7-14!43
44 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. 7-14!44
45 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. 7-14!45
46 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. 7-14!46
47 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. 7-14!47
Ohjelmistotekniikka - Luento 14 Jouni Lappalainen
Ohjelmistotekniikka - Luento 14 Jouni Lappalainen Luku 28: Riskien hallinta - reaktiivinen ja proaktiivinen riskien hallinta - riskien tunnistus, arviointi ja tarkentaminen - riskien vähentäminen, valvonta
LisätiedotOhjelmistotekniikka - Luento 2
Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit
LisätiedotOhjelmistotekniikka - Luento 2 Jouni Lappalainen
Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento
LisätiedotProsessien 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ätiedotCMM Capability Maturity Model. Software Engineering Institute (SEI) Perustettu vuonna 1984 Carnegie Mellon University
CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 13.3. CMM Capability Maturity Model Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
LisätiedotCMMI CMM -> CMMI. CMM Capability Maturity Model. Sami Kollanus TJTA330 Ohjelmistotuotanto Software Engineering Institute (SEI)
CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 13.3. CMM Capability Maturity Model Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
LisätiedotCMMI CMMI CMM -> CMMI. CMM Capability Maturity Model. Sami Kollanus TJTA330 Ohjelmistotuotanto
CMM Capability Maturity Model CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 16.1.2007 Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
LisätiedotOhjelmistotekniikka 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ätiedotJohdantoluento. 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ätiedotOhjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
LisätiedotYlläpito. Ylläpidon lajeja
Ylläpito Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective)
LisätiedotYlläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito
Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective) testausvaiheessa
LisätiedotProsessiajattelu. 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ätiedotProsessiajattelu. 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ätiedotProjektin suunnittelu
Projektin suunnittelu Sami Kollanus TJTA330 Ohjelmistotuotanto 15.3. Projektin suunnittelu - CMMIkäytänteet Projektin estimaatit: Määritellään projektin laajuus (scope) Määritellään tehtävien ja tuotosten
LisätiedotAluksi. Riskien hallinta. Riskityyppejä. Riskillä on kaksi ominaisuutta. Reaktiivinen strategia. Proaktiivinen strategia
Aluksi Riskien hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 24.1.2007 Reaktiivinen strategia Indiana Jones -tyyli Ei huolehdita ongelmista ennen kuin ne tapahtuu Proaktiivinen strategia Tunnistetaan
LisätiedotLaatukustannukset. Laadun hallinta. Laadun kustannuksista
Laatukustannukset Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 13.2.2007 US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria
LisätiedotLaadun hallinta. Laatukustannukset. Laadun kustannuksista. Sami Kollanus TJTA330 Ohjelmistotuotanto
Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 5.4. Laatukustannukset US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria
LisätiedotLaadun hallinta. Laatukustannukset. Sami Kollanus TJTA330 Ohjelmistotuotanto
Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 5.4. Laatukustannukset US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria
LisätiedotOhjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit
Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää
LisätiedotTietoEnator Pilot. Ari Hirvonen. TietoEnator Oyj. Senior Consultant, Ph. D. (Economics) presentation TietoEnator 2003 Page 1
TietoEnator Pilot Ari Hirvonen Senior Consultant, Ph. D. (Economics) TietoEnator Oyj presentation TietoEnator 2003 Page 1 Sallikaa minun kysyä, mitä tietä minun tulee kulkea? kysyi Liisa. Se riippuu suureksi
LisätiedotISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ
ISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ IMS Business Solutions Oy, J Moisio 10/ 2016 2.10.2016 IMS Business Solutions Oy 2 ISO 9001:2015 PROSESSIEN AUDITOINTIKYSYMYKSIÄ ISO 9001:2015
LisätiedotMissä mennään BI? Mikko Kontio
Missä mennään BI? Mikko Kontio Source: EMC - Big Data in 2020 % Business Intelligence Business Analytics set of theories, methodologies, architectures, and technologies that transform raw data into meaningful
LisätiedotSoftware 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ätiedotJohdanto. Mitä on ohjelmistotuotanto? Tämän kurssin näkökulma. Sami Kollanus TJTA330 Ohjelmistotuotanto
Johdanto Sami Kollanus TJTA330 Ohjelmistotuotanto 6.3. Mitä on ohjelmistotuotanto? Ohjelmistotekniikka (Software Engineering) tarkoittaa pätevien insinööriperiaatteiden vakiinnuttamista ja käyttämistä
LisätiedotMitä on ohjelmistotuotanto?
Johdanto Sami Kollanus TJTA330 Ohjelmistotuotanto 6.3. Mitä on ohjelmistotuotanto? Ohjelmistotekniikka (Software Engineering) tarkoittaa pätevien insinööriperiaatteiden vakiinnuttamista ja käyttämistä
LisätiedotVaatimusmäärittely- ja hallinta
Vaatimusmäärittely- ja hallinta TJTA330 Ohjelmistotuotanto 27.3. Peruskäsitteet Vaatimusten yhteydessä puhutaan yleensä erikseen vaatimusmäärittelystä ja vaatimusten hallinnasta Vaatimusmäärittely on vaatimusten
LisätiedotFujitsu 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ätiedotOhjelmistotuotanto, syksy laatu Ohjelmiston laatu
Ohjelmiston laatu Laatu - useita eri näkemyksiä klassinen: kaikki tarpeet huomioiva hyvyys, subjektiivinen tuote ja hintasidonnainen: mitä kallimpi sitä parempi tarkoituksenmukaisuus: laadukas tuote sopii
LisätiedotVaatimusmäärittely- ja hallinta. Peruskäsitteet. Syyt aikataulun ja budjetin ylitykseen. TJTA330 Ohjelmistotuotanto
Vaatimusmäärittely- ja hallinta TJTA330 Ohjelmistotuotanto 27.3. Peruskäsitteet Vaatimusten yhteydessä puhutaan yleensä erikseen vaatimusmäärittelystä ja vaatimusten hallinnasta Vaatimusmäärittely on vaatimusten
LisätiedotSFS, 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ätiedotMiten 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ätiedot8. Laadunvalvonta. Mitä laatu on?
8. Laadunvalvonta Ohjelmistojen laatu on parantunut paljon viimeisen 15 vuoden aikana. Tämä näkyy mm. siinä, että asiakkaat ovat keskimäärin tyytyväisempiä tuotteiden toimintaan kuin 90-luvun alussa. Tähän
LisätiedotTestaaminen 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ätiedotCopyright 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ätiedotOleelliset 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ätiedotOhjelmistotuotteen hallinnasta
Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista
LisätiedotTutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
LisätiedotKatselmoinnit. review) Katselmoinnit (review( Mitä ovat katselmoinnit? Katselmoinnin määritelmä (IEEE 1988)
Katselmoinnit Johdatus ohjelmistotekniikkaan Sami Kollanus 19.10.2004 Katselmoinnin määritelmä (IEEE 1988) An evaluation of software element(s) or projects status to ascertain discrepancies from planned
LisätiedotKehittää 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ätiedotKoekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky
Koekysymyksiä Ohjelmistoprosessit ja ohjelmistojen laatu 30.4.2015 58153003 Ohjelmistojen suorituskyky 1 Kurssikokeeseen tulee neljä koetilaisuudessa vastattavaa kysymystä KOKEESSA VASTATTAVAT KYSYMYKSET
LisätiedotInnovaatiivinen hallinta Saimaan ja Atlantin rannalla. Case: I-SSHP & Walter Reed Army Medical Center
Innovaatiivinen hallinta Saimaan ja Atlantin rannalla Case: I-SSHP & Walter Reed Army Medical Center Vain sitä voi hallita, mitä voi mitata Mitä yhteistä? Walter Reed Army Medical Center, Washington DC,
LisätiedotOhjelmointitekniikka 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ätiedotOhjelmistojen 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ätiedotOhjelmistojen mallinnus, s2008 HY/TKTL, 28/10/2008. Harri Laine 1. Ohjelmisto
jen mallinnus, s2008 jen mallinnus (OMa) - Johdatus ohjelmistotuotantoon Tietokoneohjelma (computer program) toimintaohje, jonka mukaan toimien tietokone suorittaa jonkin tietojenkäsittelytehtävän suoritettava
LisätiedotTietohallinnon 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ätiedotProjektityö
Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:
LisätiedotITK130 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ätiedot3. 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ätiedotOnnistunut 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ätiedotT Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä
LisätiedotMiten luodaan tehokas ja sertifioitu laatujärjestelmä?
Miten luodaan tehokas ja sertifioitu laatujärjestelmä? Lahden seudun Meriklusteritapaaminen tammikuu 2019 Hannu Järvelin Business Excellence Finland Oy 1 Miksi olisit kiinnostunut? Onko sinulla selvä strategia
LisätiedotHankkeiden vaikuttavuus: Työkaluja hankesuunnittelun tueksi
Ideasta projektiksi - kumppanuushankkeen suunnittelun lähtökohdat Hankkeiden vaikuttavuus: Työkaluja hankesuunnittelun tueksi Erasmus+ -ohjelman hakuneuvonta ammatillisen koulutuksen kumppanuushanketta
LisätiedotOhjelmistotuotanto, projektinhallinta Kevät 2005
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ätiedotJussi 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ätiedotJyrki 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ätiedotEstimointityökalut. Pekka Forselius, Senior Advisor Finnish Software Measurement Association FiSMA ry
Estimointityökalut Pekka Forselius, Senior Advisor Finnish Software Measurement Association FiSMA ry 1 Työkalujen rooli ohjelmistotyössä A fool with a tool is still a fool! Ohjelmistotyökalujen käyttäminen
LisätiedotSC7 Interim, Hoboken, USA WG 7 ja 10 kokoukset, marraskuu Keskeiset työkohteet ja tulokset. Timo Varkoi, Senior Advisor FiSMA
SC7 Interim, Hoboken, USA WG 7 ja 10 kokoukset, marraskuu 2015 Keskeiset työkohteet ja tulokset Timo Varkoi, Senior Advisor FiSMA Työryhmien kokous, marraskuu 2015 (SC7 Interim) Paikka: Hoboken, New Jersey,
LisätiedotLaatu 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ätiedotBig Room -toiminta tutkimuksen näkökulmasta. Sari Koskelo, Vison Oy
? Big Room -toiminta tutkimuksen näkökulmasta Sari Koskelo, Vison Oy 16.3.2018 Sisältö Big Room konseptin moniulotteisuus Tavoitteet Johtaminen Big Room toiminta kehitys- ja toteutusvaiheissa Big Room
LisätiedotTietoturvallisuus 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ätiedotProjektinhallinta SFS-ISO mukaan
Projektinhallinta SFS-ISO 21500 mukaan (Ohjeita projektinhallinnasta, 2012) 13.4.2017 Panu Kiviluoma Osaamistavoitteet Luennon jälkeen osaat selittää, mitä tarkoitetaan Projektilla Projektinhallinnalla
LisätiedotLAATU, 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ätiedotArkkitehtuuritietoisku. 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ätiedotITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan
ITSM Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan Olli Saranen Senior Consultant Avoset Oy 31.8.2016 Esittely Mukana suomalaisten pankkijärjestelmien kehittämisessä ja ylläpitotyössä
LisätiedotTietohallinnon 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ätiedotPROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS
PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS 10 KEYS TO SUCCESSFUL SOFTWARE PROJECT 1. Clear Vision 2. Stable, Complete, Written Requirements 3. Detailed User Interface Prototypes
LisätiedotSYSTEEMITYÖ. Tärkeitä sanoja
SYSTEEMITYÖ Tärkeitä sanoja SYSTEEMITYÖN TÄRKEITÄ SANOJA Laatu (itse tuotteessa ja sen tekemisessä) Dokumentaatio Riskienhallinta Vaatimustenhallinta Uudelleenkäytettävyys Versionhallinta 2 LAATU Parityönä:
LisätiedotProsessien hallinta ammatillisen koulutuksen laadunhallintasuosituksessa ja eurooppalaisessa viitekehyksessä
Prosessien hallinta ammatillisessa koulutuksessa, 21.-22.4.2010 klo 9.45-10.15, Opetushallitus Prosessien hallinta ammatillisen koulutuksen laadunhallintasuosituksessa ja eurooppalaisessa viitekehyksessä
LisätiedotPaikkatietorajapinnat 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ätiedotITK130 Ohjelmistoprosessi
ITK130 Ohjelmistoprosessi Ohjelmistotuotteen elinkaari Ohjelmistoprosessimalli Koodaa ja korjaa Miksi ohjelmistoprosesseja? Prosessimallin tavoitteet Prosessi ongelmaratkaisuna Prosessi, musta laatikko
LisätiedotOhjelmiston 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ätiedotKetterä 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ätiedotOhjelmistoarkkitehtuurit Kevät 2016 Johdantoa
Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 8.1.2014 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3
LisätiedotOHJ-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ätiedotMitä 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ätiedotTestaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:
Testaus käsite Sekalaista asiaa Sami Kollanus 15.11.2006 Jos ajatellaan, että = V&V, voidaan erottaa: Staattinen Dynaaminen Toisaalta voidaan määritellä Myersin (1979) mukaan: Testaus on ohjelman suoritusta,
LisätiedotLiite 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ätiedotProjektinhallinta: riskeihin varautuminen
Projektinhallinta: riskeihin varautuminen 581259 Ohjelmistotuotanto 325 Riskienhallinta Projektin valmistuminen pyritään takaamaan myös tilanteissa, joissa tapahtuu jotakin, mikä uhkaa projektin onnistumista
LisätiedotTietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto
LisätiedotProsessien 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ätiedotMäärittely- ja suunnittelumenetelmät
Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka
LisätiedotTyömäärän arviointi. Vaihtoehtoja. Sami Kollanus TJTA330 Ohjelmistotuotanto
Työmäärän arviointi Sami Kollanus TJTA330 Ohjelmistotuotanto 20.3. Vaihtoehtoja Arvioidaan projektin jälkeen (onnistuu varmasti) Verrataan karkeasti samanlaisiin aiempiin projekteihin Ositetaan projekti
LisätiedotTyömäärän arviointi. Vaihtoehtoja. Arviointiprosessi. Sami Kollanus TJTA330 Ohjelmistotuotanto
Työmäärän arviointi Sami Kollanus TJTA330 Ohjelmistotuotanto 20.3. Vaihtoehtoja Arvioidaan projektin jälkeen (onnistuu varmasti) Verrataan karkeasti samanlaisiin aiempiin projekteihin Ositetaan projekti
LisätiedotAutomaatiojä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ätiedotGreen Growth Sessio - Millaisilla kansainvälistymismalleilla kasvumarkkinoille?
Green Growth Sessio - Millaisilla kansainvälistymismalleilla kasvumarkkinoille? 10.10.01 Tuomo Suortti Ohjelman päällikkö Riina Antikainen Ohjelman koordinaattori 10/11/01 Tilaisuuden teema Kansainvälistymiseen
LisätiedotSecurity server v6 installation requirements
CSC Security server v6 installation requirements Security server version 6.x. Version 0.2 Pekka Muhonen 2/10/2015 Date Version Description 18.12.2014 0.1 Initial version 10.02.2015 0.2 Major changes Contents
LisätiedotNESTE ENGINEERING SOLUTIONS
NESTE ENGINEERING SOLUTIONS Functional safety assessment ASAF teemapäivä Jari Koivuvirta Automation, Functional Safety Neste Engineering Solutions Mobile: +358 50 458 9756 e-mail: jari.koivuvirta@neste.com
LisätiedotProsessikuvaukset 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ätiedotSuunnittelun ja rakentamisen nykytila
"MUUTTUVA SUUNNITTELUPROSESSI" Integroitu suunnitteluprosessi - mahdollisuus liiketoiminnan laajentamiseen? Reijo Hänninen Toimitusjohtaja Insinööritoimisto Olof Granlund Oy VERA - SEMINAARI Dipoli, Espoo
LisätiedotProjektin suunnittelu A71A00300
Projektin suunnittelu A71A00300 PESTLE-malli Poliittinen - mitä poliittisia riskejä projektiin voi liittyä? (verotus, hallinto ) Ekonominen - mitä taloudellisia riskejä projektiin liittyy? (työvoiman saatavuus,
LisätiedotUusi Ajatus Löytyy Luonnosta 4 (käsikirja) (Finnish Edition)
Uusi Ajatus Löytyy Luonnosta 4 (käsikirja) (Finnish Edition) Esko Jalkanen Click here if your download doesn"t start automatically Uusi Ajatus Löytyy Luonnosta 4 (käsikirja) (Finnish Edition) Esko Jalkanen
LisätiedotProsessien kehittäminen osa 2
Prosessien kehittäminen osa 2 Sami Kollanus TJTA330 Ohjelmistotuotanto 26.4. SEI:n mukan kolme odotettavissa olevaa ongelmaa Tämä ei sovellu meille Resurssit valuvat prosessien kehittämisestä tärkeämpiin
LisätiedotProsessien kehittäminen osa 2
Prosessien kehittäminen osa 2 Sami Kollanus TJTA330 Ohjelmistotuotanto 26.4. SEI:n mukan kolme odotettavissa olevaa ongelmaa Tämä ei sovellu meille Resurssit valuvat prosessien kehittämisestä tärkeämpiin
LisätiedotProjektin suunnittelu 71A00300
Projektin suunnittelu 71A00300 Tiimijako Projektisuunnitelma 1. 2. 3. 4. 5. 6. 7. Projektitiimi Projektin tausta Projektin tavoitteet Tiimin roolit Sisäinen viestintä Riskianalyysi Aikataulutus Projektisuunnitelman
LisätiedotOrganisaation kokonaissuorituskyvyn arviointi
Organisaation kokonaissuorituskyvyn arviointi Aila Järveläinen, 13.3.2018 aila.jarvelainen@trafi.fi Responsible traffic. Courage and co-operation. Hallintojärjestelmä CMS + SMS CMS SMS 29.3.2018 Finnish
LisätiedotISO Standardisarja Eräitä ulottuvuuksia Kari Komonen
ISO 55000 Standardisarja Eräitä ulottuvuuksia 6.11.2014 Kari Komonen Eräitä käsitteitä omaisuus, omaisuuserä kohteet, asiat tai kokonaisuudet, joilla on tai voi olla arvoa organisaatiolle omaisuudenhallinta
LisätiedotRAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS
RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS Loppuseminaari 11.12.2018 YIT:n pääkonttori, Helsinki RAIN hankkeen loppuseminaari 11.12.2018 Käyttäjälähtöinen tiedonhallinta (WP 4) Professori Harri Haapasalo OY
LisätiedotSecurity 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ätiedotOhjelmistojen suunnittelu
Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer
Lisätiedot