Source: http://docplayer.fi/368247-Iec-61508-3-sisalto-ja-rakenne.html
Timestamp: 2016-10-24 00:38:51+00:00
Document Index: 4226031

Matched Legal Cases: ['kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ']

⭐IEC sisältö ja rakenne
IEC sisältö ja rakenne
Download "IEC 61508-3 sisältö ja rakenne"
1 1(41) IEC sisältö ja rakenne Matti Vuori, Tampereen teknillinen yliopisto Huom! Esityksessä käytetyt standardin suomenkieliset tekstit, termit ja kaaviot ovat standardin käännöksen vielä hyväksymättömästä versiosta ja saattavat siten osin muuttua standardin julkaistavassa versioon2 Sisällysluettelo 1/3 Asema koko standardisarjassa 5 Tiukasti kiinni ohjelmoitavan elektroniikan kehityksen kanssa 6 Soveltamisen perusfilosofia 7 Soveltamisen perusfilosofia 8 Prosessimallina V-malli mutta muitakin voi soveltaa 9 Tukee laadukkaan ohjelmistokehityksen ideaaleja 10 Milloin sovelletaan? 11 Ohjelmiston turvallisuuden elinkaari 12 Rakenne ja sisältö Luvut Rakenne ja sisältö Luku 7 / Rakenne ja sisältö Luku 7.1 & Rakenne ja sisältö Luku Rakenne ja sisältö Luku3 Sisällysluettelo 2/3 Rakenne ja sisältö Luku Rakenne ja sisältö Luku 7.5 & Rakenne ja sisältö Luku Rakenne ja sisältö Luku Rakenne ja sisältö Luku Rakenne ja sisältö Luku Rakenne ja sisältö Luku 8 24 Standardin liitteet 25 Taulukkoesimerkki liitteestä A 27 Liitteen A taulukot 28 Liitteen B taulukot linkittyvät A-taulukoihin 30 Liite C Tarkoitus 31 Liite C Peruskäyttö 324 Sisällysluettelo 3/3 Liite C.2 Taulukot 35 Apu ketterään kehittämiseen standardin mukaisesti 38 Patterneista apua ymmärtämiseen 39 Lähteitä ja viitteitä 40 Kiitos 415 Asema koko standardisarjassa 5(41) Tiukasti kiinni :ssa Menetelmäopastusta :ssä Ymmärrettävä :n konteksti6 Tiukasti kiinni ohjelmoitavan elektroniikan kehityksen kanssa 6(41)7 7(41) Soveltamisen perusfilosofia Perustuu turvallisuuden elinkaari ajatteluun: turvallisuusvaatimuksista systeemin validointiin ja käyttöjaksoon. Ei riskien kvantifiointia, vaan toimia systemaattisten ohjelmistovirheiden estämiseen. Ohjelmistolle allokoidut turvallisuusvaatimukset ja SIL-taso ovat lähtötietoina. Kehyksenä traditionaalinen näkemys ohjelmistokehityksen prosessista V-malli (mutta muitakin prosesseja voi käyttää). Systemaattinen ketju vaatimuksista toteutukseen ja verifioinnin kautta paluu ylätasolle erilaisten testausvaiheiden kautta. Traditionaalisia systemaattisen ohjelmistokehityksen menetelmiä ja laatutekniikoita, mutta myös uusia, vaativia tekniikoita (SIL 3-4). Menettelyt valitaan SIL-tason perusteella.8 8(41) Soveltamisen perusfilosofia Jämäkkä prosessi: Sekä alku- että loppupää ja kaikki siltä väliltä. Vaatimusmäärittely kokonaisjärjestelmän vaatimuksiin perustuen. Arkkitehtuurin laatu. Suunnittelun ja toteutuksen laatu. Verifioinnin laatu testauksen yms. laatu. Turvallisuuden arviointi aina, kun suunnitteluratkaisuja muutetaan, Validointi suhteessa siihen, mitä oikeasti tarvitaan, eli kokonaisjärjestelmän puitteissa. Tiukka dokumentointi. Erittäin vahva konfiguraationhallinta ja asioiden jäljitys. Osaamisvaatimukset ja vastuut. Vastaa monia traditionaalisia näkemyksiä hyvästä ohjelmistotuotannosta.9 Prosessimallina V-malli mutta muitakin voi soveltaa 9(41) Katselmointi, tarkastaminen analysointi10 Tukee laadukkaan ohjelmistokehityksen ideaaleja 10(41) Menettelyissä on erilaisia parhaita käytäntöjä ja tiukkaa jämäkkyyttä. Standardille saa siksi tukea ohjelmistokehityksen laatuun liittyvistä standardeista ja kehysmalleista. Esimerkiksi: Laadunhallintajärjestelmästandardi: ISO 9001:n sovellusstandardi ISO Guidelines for the application of ISO 9001:2000 to computer software suh. konkreettisia ohjeita hyvä standardi, mutta vähän tunnettu Kypsyysmallistandardi: CMMI for Development,11 11(41) Milloin sovelletaan? Ohjelmistojen kehittäminen :n määrittämässä kontekstissa Rajanveto: mikä on ohjelmointia ja mikä konfigurointia? Oikea ohjelmointi purkkien sisällä Tekstuaaliset ohjelmointikielet Yleiskäyttöiset ohjelmointikielet, C# Jos turvajärjestelmää ei voi erottaa tuotannollisesta järjestelmästä, kokonaisuus kuuluu tämän standardin piiriin12 Ohjelmiston turvallisuuden elinkaari 12(41)13 13(41) Rakenne ja sisältö Luvut Määritelmät ja lyhenteet Viittaus: IEC Standardinmukaisuus Vaatimukset standardin IEC luvussa 4. 5 Dokumentaatio Tavoitteet ja vaatimukset standardin IEC luvussa 5 6 Lisävaatimukset turvallisuuteen liittyvän ohjelmiston hallintaan Strategia koko toimintaan Konfiguraationhallinta Muutoksenhallinta: valtuus, dokumentointi, konfiguraationhallinta14 14(41) Rakenne ja sisältö Luku 7 / Ohjelmiston turvallisuuden elinkaaren vaatimukset 7.1 Yleistä Turvallisuuden elinkaaren ja ohjelmistokehityksen elinkaaren määrittäminen V-mallin voi korvata, kunhan vaatimukset täyttyvät Ketteristä projektimalleista myöhemmin Elinkaaressa vahvasti turvallisuuden ja laadun toimenpiteet Dokumentointi Kun elinkaarimallissa iteroidaan, on tarvittavat muutokset analysoitava15 15(41) Rakenne ja sisältö Luku 7.1 & Ohjelmiston turvallisuusvaatimusten määrittely Syntetisoidaan vaatimukset lähtien kokonaisjärjestelmästä ja miten turvallisuusvaatimukset on allokoitu Yksityiskohtaisuus ja dokumentointi 7.3 Kelpuutussuunnitelma järjestelmän turvallisuuden ohjelmistoosuudelle Miten turvallisuusvaatimusten täyttyminen osoitetaan Miten, kuka, koska Missä ympäristössä Kaikenlaiset käyttötilanteet Perustelu valinnoille Tarkka esim. testien dokumentointi16 16(41) Rakenne ja sisältö Luku Ohjelmistosuunnittelu ja ohjelmiston kehittäminen Kuka vastaa - toimittaja, kehittäjä Valittava oikeat suunnittelumenetelmät, joilla hallitaan turvallisuuskriittisten sulautettujen järjestelmien haasteet Suunnittelussa otettava huomioon testattavuus ja muutettavuus Yksinkertaisuus toteutuksissa! Jos turvatoimintoja ei voida erottaa, on koko ohjelmistoa käsiteltävä turvallisuuskriittisenä Hyväksymiskriteerit aiemmille komponenteille kuten ohjelmoitavalle elektroniikalle -- mutta ohjelmiston uudelleenkäyttö aina invalidoi sen käytännössä pitkälti Hyvä arkkitehtuurisuunnittelu17 17(41) Rakenne ja sisältö Luku 7.4 Ajonaikaiset "tukityökalut" ovat ohjelmiston elementti (lähtöjä tuottavat, testausvälineet) Ohjelmointikielet ovat ohjelmiston elementti eli kehittämistyökalut on hallittava yhtä hyvin kuin kehitettävä ohjelma Ohjelman koodin oltava hyvää Moduulit testattava hyvin: kattavasti, toistettavasti, määritellyssä ympäristössä... tavallista systemaattista testausta Todentaminen suunnitelman mukaisesti - ketterä testaus ei riitä Negatiivinen testaus oleellista - ohjelma ei saa tehdä mitään, mitä se ei saisi; häiriöiden hallinta, robustius Moduulien integrointi suunnitelman mukaisesti Huom! Kaksi integrointitasoa: ohjelman moduulien integrointi ja ohjelman integrointi ohjelmoitavaan elektroniikkaan18 18(41) Rakenne ja sisältö Luku 7.4 Ajonaikaiset "tukityökalut" ovat ohjelmiston elementti (lähtöjä tuottavat, testausvälineet) Ohjelmointikielet ovat ohjelmiston elementti -- eli kehittämistyökalut on hallittava yhtä hyvin kuin kehitettävä ohjelma Ohjelman koodin oltava hyvää Moduulit testattava hyvin: kattavasti, toistettavasti, määritellyssä ympäristössä... tavallista systemaattista testausta Todentaminen suunnitelman mukaisesti - ketterä testaus ei riitä Negatiivinen testaus oleellista - ohjelma ei saa tehdä mitään, mitä se ei saisi; häiriöiden hallinta, robustius Moduulien integrointi suunnitelman mukaisesti Huom! Kaksi integrointitasoa: ohjelman moduulien integrointi ja ohjelman integrointi ohjelmoitavaan elektroniikkaan19 19(41) Rakenne ja sisältö Luku 7.5 & Ohjelmoitavan elektroniikan integrointi (laitteisto ja ohjelmisto) Testit määritetään suunnittelu- ja kehitysvaiheessa (eli ei ad-hoc mutta tietenkin ketterä, tutkiva testaus on tärkeää käytännössä) Erotettava kehittäjän tiloissa tehtävät testit ja ne, joita pitää tehdä asiakkaan tiloissa Jos integroinnin aikana tehdään muutoksia, niille vaikutusanalyysi Testien kattava dokumentointi 7.6 Ohjelmiston käytön ja muutosten tekemisen menettelytavat Vaatimukset standardin IEC kohdassa 7.6 ja tämän standardin kohdassa 7.820 20(41) Rakenne ja sisältö Luku Järjestelmän turvallisuuden kelpuutus (validointi) ohjelmiston osalta Jos kelpuutus tehdään ohjelmoitavan elektroniikan kelpuutuksen myötä, sitä ei tarvitse toistaa Kelpuutus kuin on määritetty järjestelmän turvallisuuden ohjelmistoosuuksien kelpuutussuunnitelmassa Vastuu voi jakautua eri osapuolille -- eli toimittaja hoitaa oman osuutensa Tulosten tallennus Jos jokin ei onnistu, tietoinen päätös kelpuutuksen jatkosta tai keskeytyksestä ja muutospyynnöstä Pitää kelpuuttaa kaikki ohjelmiston turvallisuusvaatimukset Testit dokumentoitava riippumatonta arviointia varten21 21(41) Rakenne ja sisältö Luku Ohjelmiston muutokset Pitää olla määritetty muutosprosessi Valtuutettu muutospyyntö: Kannanotto, mihin vaaroihin vaikuttaa, syy muutokseen Vaikutusanalyysi: pitääkö toistaa riskianalyysi; mihin prosessin vaiheisiin vaikuttaa Muutoksen toteutus suunnitelman mukaan Dokumentointi22 22(41) Rakenne ja sisältö Luku Ohjelmiston todentaminen (verifiointi) Elinkaaren eri vaiheissa Todennetaan (mm.) a) ohjelmiston turvallisuusvaatimukset, b) ohjelmistoarkkitehtuuri, c) ohjelmistojärjestelmän toteutus, d) ohjelmistomoduulien toteutus, e) koodi, f) tiedot (tietorakenteet, sovellustiedot), g) ajoitukset, h) ohjelmistomoduulit, i) ohjelmiston integrointi, j) ohjelmoitavan elektroniikan integrointi, k) järjestelmän turvallisuuden ohjelmisto-osuus23 23(41) Rakenne ja sisältö Luku 7.9 Testauksen ohella monia muita tekniikoita Todentamisen täysi kattavuus elinkaaren edellisen vaiheen suhteen: todentamisen oikeellisuus elinkaaren edellisen vaiheen suhteen (onnistunut loppuun saattaminen), toistettavuus, tarkasti määritelty todentamisen konfiguraatio Todentaminen on suunniteltava samanaikaisesti kehittämistoiminnan kanssa jokaiselle ohjelmiston turvallisuuden elinkaaren vaiheelle Ohjelmiston todentamisen suunnittelun on viitattava kriteereihin, tekniikoihin ja työkaluihin, joita käytetään Dokumentoitava näyttö osoittamaan, että todennettava vaihe on kaikilta osin tyydyttävästi loppuun suoritettu Todennettaessa on oltava kaikki tarpeelliset tiedot Tiukka todennettavan konfiguraation yksilöinti24 24(41) Rakenne ja sisältö Luku 8 8 Toiminnallisen turvallisuuden arviointi Perusteet :ssä Arvioijien riippumattomuusvaatimukset: omaa porukkaa, toinen yksikkö, ulkopuolinen? IEC , luku 8 Käytetään A.10:n tuloksia25 25(41) Standardin liitteet 1/2 Varsinainen ongelma on liitteissä, joissa kuvataan tarvittavia menettelyjä eri SIL-tasoille Miten osataan valita sopivat menetelmät, jotka täyttävät vaatimukset ja joita osataan käyttää? (Standardin uudistus toi haasteita mm. verifiointimenetelmiin) Liite A: Ohje tekniikoiden ja toimenpiteiden valintaan Velvoittava Tekniikoiden edellyttäminen: HR, R,, NR Liite B: Yksityiskohtaiset taulukot Opastava Lisätietoa vastaaviin A-taulukoihin26 26(41) Standardin liitteet 2/2 Liite C: Ohjelmiston systemaattisen kyvykkyyden ominaisuudet Ohjeita tiettyjen liitteiden A ja B tekniikoiden valintaan ohjelmiston systemaattisen kyvykkyyden saavuttamiseksi Perusteluja niiden tekniikoiden käyttämiseksi, joita ei ole eksplisiittisesti lueteltu liitteissä A ja B. Liite D: Turvallisuuskäsikirja vaatimustenmukaisille osille lisävaatimuksia ohjelmiston elementeille Liite E: Standardien IEC ja IEC suhde Opastava Liite F: Tekniikat, joilla saavutetaan ohjelmistoelementtien välinen erillisyys yhdessä tietokoneessa Opastava Liite G: Ohjeita elinkaaren räätälöintiin tieto-ohjattujen järjestelmien yhteydessä Opastava27 Taulukkoesimerkki liitteestä A 27(41) Taulukko A.1 Ohjelmiston turvallisuusvaatimusten määrittely28 28(41) Liitteen A taulukot 1/2 Taulukko A.1 Ohjelmiston turvallisuusvaatimusten määrittely (Katso 7.2) Taulukko A.2 Ohjelmistosuunnittelu ja ohjelmiston kehittäminen ohjelmistoarkkitehtuurin suunnittelu (katso 7.4.3) Taulukko A.3 Ohjelmistosuunnittelu ja ohjelmiston kehittäminen - tukityökalut ja ohjelmointikieli (katso 7.4.4) Taulukko A.4 Ohjelmistosuunnittelu ja ohjelmiston kehittäminen yksityiskohtainen suunnittelu (katso ja 7.4.6) (Sisältää ohjelmistojärjestelmän suunnittelun, ohjelmistomoduulien suunnittelun ja koodauksen) Taulukko A.5 - Ohjelmistosuunnittelu ja ohjelmiston kehittäminen ohjelmistomoduulien testaus ja integrointi (Katso ja 7.4.8)29 29(41) Liitteen A taulukot 2/2 Taulukko A.6 Ohjelmoitavan elektroniikan integrointi (ohjelmisto ja laitteisto) (katso 7.5) Taulukko A.7 Järjestelmän turvallisuuden kelpuutus ohjelmiston näkökulmasta (katso 7.7) Taulukko A.8 Muutokset (katso 7.8) Taulukko A.9 Ohjelmiston todentaminen (katso 7.9) Taulukko A.10 Toiminnallisen turvallisuuden arviointi (katso Luku 8)30 Liitteen B taulukot linkittyvät A- taulukoihin 30(41) Taulukko B.1 Suunnittelu- ja koodausstandardit (Viittaukset taulukosta A.4) Taulukko B.2 Dynaaminen analyysi ja testaus (Viittaukset taulukoista A.5 ja A.9) Taulukko B.3 Toiminnallinen testaus ja mustalaatikkotestaus (Viittaukset taulukoista A.5, A.6 ja A.7) Taulukko B.4 Vika-analyysi (Viittaukset taulukosta A.10) Taulukko B.5 Mallintaminen (Viittaukset taulukosta A.7) Taulukko B.6 Suorituskykytestaus (Viittaukset taulukoista A.5 ja A.6) Taulukko B.7 Semiformaalit menetelmät (Viittaukset taulukoista A.1, A.2 ja A.4) Taulukko B.8 Staattinen analyysi (Viittaukset taulukosta A.9) Taulukko B.9 Modulaarinen lähestymistapa (Viittaukset taulukosta A.4)31 31(41) Liite C Tarkoitus Kun otetaan huomioon se suuri määrä tekijöitä, jotka vaikuttavat ohjelmiston systemaattiseen kyvykkyyteen, ei ole mahdollista esittää algoritmia niiden tekniikoiden ja toimenpiteiden yhdistämiseen, jotka ovat oikeita mihin tahansa sovellukseen. Liitteen C tarkoitus on: Esittää ohjeita tiettyjen liitteiden A ja B tekniikoiden valintaan ohjelmiston systemaattisen kyvykkyyden saavuttamiseksi Hahmotella perustelut niiden tekniikoiden käyttämiseksi, joita ei ole eksplisiittisesti lueteltu liitteissä A ja B. Muitakin menetelmiä siis voi käyttää kunhan niiden käytön perustelee. Liite C on täydennys liitteiden A ja B taulukoihin.32 Liite C Peruskäyttö 1/3 32(41) Taulukko A.1 esittää toimenpiteitä turvallisuusvaatimusten määrittämiseen, mutta tässä ei ole vielä koko totuus33 Liite C Peruskäyttö 2/3 33(41) Taulukko C.1 kertoo, miten toimenpiteet tukevat systeemin ominaisuuksia, kun pyritään toimimaan tietyllä tarkkuudella (rigour, esim. R1, R2, R3)34 Liite C Peruskäyttö 3/3 34(41) Tarkkuustasot R1 R2 R3 _ Ilman objektiivisia hyväksymiskriteerejä tai rajoitetuilla objektiivisilla hyväksymiskriteereillä, esimerkiksi arviointiin perustuva mustalaatikkotestaus ja kenttäkokeet. Objektiivisilla hyväksymiskriteereillä, jotka voivat tuoda korkean tason luottamuksen sille, että vaadittu ominaisuus saavutetaan (poikkeukset on yksilöitävä ja perusteltava, esim. testi- tai analyysitekniikat ml. kattavuusmittaus tai tarkistuslistojen kattavuus.) Objektiivisella, systemaattisella päättelyllä, jolla saavutetaan vaadittava ominaisuus, esim. formaali todistaminen ja pitäytyminen arkkitehtuurin rajoituksiin, jotka varmistavat kyseisen ominaisuuden. Tämä tekniikka ei ole asiaankuuluva tälle ominaisuudelle.35 35(41) Liite C.2 Taulukot 1/3 Kokoelma 1: Systemaattisen turvallisuuden eheyden ominaisuudet Viitteet standardin lukuihin ja A-taulukoihin Taulukko C.1 Systemaattisen turvallisuuden eheyden ominaisuudet Ohjelmiston turvallisuusvaatimusten määrittely Taulukko C.2 Systemaattisen turvallisuuden eheyden ominaisuudet Ohjelmistosuunnittelu ja ohjelmiston kehittäminen ohjelmistoarkkitehtuurin suunnittelu Taulukko C.3 Systemaattisen turvallisuuden eheyden ominaisuudet Ohjelmistosuunnittelu ja ohjelmiston kehittäminen tukityökalut ja ohjelmointikielet Taulukko C.4 Systemaattisen turvallisuuden eheyden ominaisuudet Ohjelmistosuunnittelu ja ohjelmiston kehittäminen yksityiskohtainen suunnittelu (mukaan lukien ohjelmistojärjestelmän suunnittelu, ohjelmistomoduulien suunnittelu ja koodaus) Taulukko C.5 - Systemaattisen turvallisuuden eheyden ominaisuudet Ohjelmiston testaus ja kehittäminen ohjelmistomoduulien testaus ja integrointi36 36(41) Liite C.2 Taulukot 2/3 Taulukko C.6 Systemaattisen turvallisuuden eheyden ominaisuudet Ohjelmoitavan elektroniikan integrointi (laitteisto ja ohjelmisto) Taulukko C.7 Systemaattisen turvallisuuden eheyden ominaisuudet Systemaattisen turvallisuuden näkökulma ohjelmistoon Taulukko C.8 Systemaattisen turvallisuuden eheyden ominaisuudet Ohjelmiston muuttaminen Taulukko C.9 Systemaattisen turvallisuuden eheyden ominaisuudet Ohjelmiston todentaminen Taulukko C.10 Systemaattisen turvallisuuden eheyden ominaisuudet Toiminnallisen turvallisuuden arviointi37 37(41) Liite C.2 Taulukot 3/3 Kokoelma 2: Systemaattisen turvallisuuden eheyden ominaisuudet Yksityiskohtaiset taulukot Viitteet B-taulukoihin Taulukko C.11 Yksityiskohtaiset ominaisuudet Suunnittelu ja koodausstandardit Taulukko C.12 Ominaisuuksien yksityiskohdat Dynaaminen analyysi ja testaus Taulukko C.13 Ominaisuuksien yksityiskohdat Toiminnallinen ja mustalaatikkotestaus Taulukko C.14 Ominaisuuksien yksityiskohdat Vika-analyysit Taulukko C.15 Ominaisuuksien yksityiskohdat - Mallintaminen Taulukko C.16 Ominaisuuksien yksityiskohdat Suorituskykytestaus Taulukko C.17 Ominaisuuksien yksityiskohdat semiformaalit menetelmät Taulukko C.18 Systemaattisen turvallisuuden eheyden ominaisuudet Staattinen analyysi Taulukko C.19 Ominaisuuksien yksityiskohdat Modulaarinen lähestymistapa38 Apu ketterään kehittämiseen standardin mukaisesti 38(41) Standardin ajattelumalli perustuu pitkälti perinteisiin ohjelmistokehitysmalleihin ja varsinkin ns. V-malliin. Jos yrityksessä käytetään ketteriä kehittämismalleja, pitää varmistaa, että kaikki standardin vaatima tulee tehtyä. TTY:llä tehtiin työ, jossa analysoitiin ketterän kehittämisen soveltamista turvallisuuskriittisten järjestelmien kehittämiseen ja miten 61508:n asiat voidaan toteuttaa ketterässä ohjelmistokehityksessä. Raportti Agile Development of Safety-Critical Software löytyy netistä PDF:nä. Osoite: ks. lähteitä-kalvo.39 39(41) Patterneista apua ymmärtämiseen Ns. patterneja käytetään usein toiminnan toistuvien asioiden kuvaamiseen puoliformaalilla, säännönmukaisella tavalla Jokin työnkulku, aliprosessi, tapa tehdä asioita, tapa toimia Systemaattiset tehtävät ja myös organisaation epäviralliset toimintamallit TTY:llä tehtiin työ, jossa niitä sovellettiin 61508:n, erityisesti :n asioiden kuvaamiseen tiiviinä toimintamalleina Raportti Safety Process Patterns In the Context of IEC löytyy netistä PDF:nä. Osoite: ks. Lähteitä-kalvo.40 Lähteitä ja viitteitä 40(41) Vuori, M., Virtanen, H., Koskinen, J. & Katara, M Safety Process Patterns In the Context of IEC Tampere University of Technology. Department of Software Systems. Report p. Available at: (Tai hae sivulla: Vuori, M Agile Development of Safety-Critical Software. Tampere University of Technology. Department of Software Systems. Report p. Available at: (Tai hae sivulla:41 41(41) Kiitos Yhteystiedot: Matti Vuori Tampereen teknillinen yliopisto Ohjelmistotekniikan laitos Samankaltaiset tiedostot
TUKES OPAS TURVA-AUTOMAATIO PROSESSITEOLLISUUDESSA Turva-automaatio prosessiteollisuudessa Turva-automaatio prosessiteollisuudessa Turva-automaatio prosessiteollisuudessa Prosessilaitosten ja prosessien Lisätiedot Olioiden pysyvyyteen ja käyttäytymiseen liittyviä suunnittelumalleja uudelleenkäytettävyyden näkökulmasta
Olioiden pysyvyyteen ja käyttäytymiseen liittyviä suunnittelumalleja uudelleenkäytettävyyden näkökulmasta Timo Väänänen 13.6.2008 Joensuun yliopisto Tietojenkäsittelytiede Pro gradu-tutkielma Tiivistelmä Lisätiedot 1 MÄÄRITELMÄT... 3 2 JOHDANTO... 5
LIIKENNEVIRASTO OHJE 2 (26) Sisällysluettelo 1 MÄÄRITELMÄT... 3 2 JOHDANTO... 5 3 YLEISTÄ... 5 3.1 YTM-asetuksen tavoite... 5 3.2 YTM-asetuksen soveltaminen... 6 3.3 Ehdottaja vastaa riskienhallinnan toteuttamisesta... Lisätiedot ROPE SIDEBRAS TESTAUSPROSESSIN KEHITTÄMINEN OHJELMISTON KÄYTTÖÖNOTTOPROJEKTISSA. Diplomityö
ROPE SIDEBRAS TESTAUSPROSESSIN KEHITTÄMINEN OHJELMISTON KÄYTTÖÖNOTTOPROJEKTISSA Diplomityö Tarkastaja: professori Hannu Jaakkola Tarkastaja ja aihe hyväksytty Tuotantotalouden ja rakentamisen tiedekunnan Lisätiedot Käytettävyysohjattu vuorovaikutussuunnittelu: JFunnel malli ( käytettävyyssuppilo )
1 (13) Käytettävyysohjattu vuorovaikutussuunnittelu: JFunnel malli ( käytettävyyssuppilo ) Timo Jokela, FT timo.jokela@joticon.fi Tiivistelmä Tämän dokumentissa kuvataan käyttäjäkeskeisen suunnittelun Lisätiedot Miia Martinsuo & Marja Blomqvist Prosessien mallintaminen osana toiminnan kehittämistä
Tampereen teknillinen yliopisto. Teknis-taloudellinen tiedekunta. Opetusmoniste 2 Tampere University of Technology. Faculty of Business and Technology Management. Lecture Notes 2 Miia Martinsuo & Marja Lisätiedot ANALYYSIMENETELMÄN KEHITTÄMISEN TOIMINTAMALLI
Tiina Päällysaho, Centria ANALYYSIMENETELMÄN KEHITTÄMISEN TOIMINTAMALLI Maaliskuu 2013 2 Sisältö 1 JOHDANTO 1-3 2 ANALYYSIMENETELMÄN KEHITTÄMISEN LÄHTÖKOHDAT 2-4 3 ANALYYSIMENETELMÄN KEHITTÄMISEN VAIHEET Lisätiedot Palveluarkkitehtuurin soveltaminen terveydenhuollossa. Osa 2: prosessien ja palvelujen määrittely ja suunnittelu
Palveluarkkitehtuurin soveltaminen terveydenhuollossa Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Tekijät Päiväys 31.8.2007 Juha Mykkänen, Heli Luostarinen, Assi Pöyhölä, Esa Paakkanen, Marko Lisätiedot JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen
JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Versio: 1.1 5.10.2012 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Johdanto... 3 1.1 ICT-palvelujen kehittäminen Lisätiedot OSA I. oppiscrum-opas
OSA I oppiscrum-opas Pedagogisia keinoja yrittäjämäiseen oppimiseen, oppimisen omistajuuteen sekä oppimisen iloon yrittäjämäistä toimintaa tukevassa oppimisympäristössä Oppimisen kehä kiertyy ja oppimisen Lisätiedot Tapaustutkimus: Miten käyttäjälähtöisyys ja Universal Design on otettu huomioon suunnitellessa käyttöliittymää kuntoharjoituslaitteisiin?
Tapaustutkimus: Miten käyttäjälähtöisyys ja Universal Design on otettu huomioon suunnitellessa käyttöliittymää kuntoharjoituslaitteisiin? Lapin yliopisto Taiteiden tiedekunta Teollinen muotoilu Syksy 2013 Lisätiedot Luku 15 Muita projektinhallinnan menetelmiä
Luku 15 Muita projektinhallinnan menetelmiä Johdanto Luvussa 15 tarkastellaan muutamia monista muista projektinhallinnan menetelmistä. Tämä luku on pikainen katsaus käsiteltävien menetelmien tyyliin, lähestymistapaan Lisätiedot Pauliina Ikävalko. Ohjelmistotuotteen käyttöliittymä, sen suunnittelu ja suunnittelija
Pauliina Ikävalko Ohjelmistotuotteen käyttöliittymä, sen suunnittelu ja suunnittelija 2 Sisällysluettelo Sisällysluettelo... 2 Johdanto... 3 Ohjelmistotuotteen käyttöliittymä... 5 HYVÄ KÄYTTÖLIITTYMÄ... Lisätiedot PROSESSIEN KEHITTÄMINEN KUNTIEN TEKNISELLÄ SEKTORILLA
Matti Toivonen & Tiina Ramstedt-Sen & Ari-Veikko Anttiroiko PROSESSIEN KEHITTÄMINEN KUNTIEN TEKNISELLÄ SEKTORILLA KUPERA-hankkeen raportti Tampereen yliopisto Johtamiskorkeakoulu Tampere 2011 SISÄLLYSLUETTELO Lisätiedot Projekti: Suunnittelun ergonomisen laadun parantaminen kokoonpanoteollisuudessa Tampere 1.4.1994
Työsuojelurahaston tutkimusohjelma Hyvä suunnittelukäytäntö työpaikkasuunnittelun kehittämiseen Projekti: Suunnittelun ergonomisen laadun parantaminen kokoonpanoteollisuudessa Tampere 1.4.1994 Matti Vuori Lisätiedot Tietoturvallisuuden hallinnan suunnittelu ja toteutus. Projektiopas valtionhallinnon organisaation tietoturvallisuudesta vastaavalle
Tietoturvallisuuden hallinnan suunnittelu ja toteutus Projektiopas valtionhallinnon organisaation tietoturvallisuudesta vastaavalle Kirsi Nurmi, 2011 Kirsi Nurmi Järvenpää 2011 ISBN 978-952-92-9055-0 (PDF) Lisätiedot Selittävät huomautukset
EUROOPAN KOMISSIO VEROTUKSEN JA TULLILIITON PÄÄOSASTO Välillinen verotus ja verohallinto Arvonlisävero Julkaistu 3. huhtikuuta 2014 Selittävät huomautukset Vuonna 2015 voimaan tulevat EU:n arvonlisäverotusta Lisätiedot Opiskelijoiden mentaaliset mallit ohjelmien suorituksesta ohjelmoinnin peruskurssilla. Vesa Vainio
Opiskelijoiden mentaaliset mallit ohjelmien suorituksesta ohjelmoinnin peruskurssilla Vesa Vainio Kognitiotieteen pro gradu -tutkielma Psykologian laitos Käyttäytymistieteellinen tiedekunta Helsingin yliopisto Lisätiedot Testausprosessimalli, yksikkötestaus ja testausympäristön automatisointi Java-ympäristössä
EVTEK-ammattikorkeakoulu Mediatekniikan koulutusohjelma Sara Kapli Testausprosessimalli, yksikkötestaus ja testausympäristön automatisointi Java-ympäristössä Insinöörityö 10.5.2005 Työn ohjaaja: Production Lisätiedot Systemaattinen layout-suunnittelu
LAPPEENRANNAN TEKNILLINEN YLIOPISTO Teknillinen tiedekunta Kemiantekniikan osasto Prosessitekniikan laboratorio Kandidaatintyö Systemaattinen layout-suunnittelu Ohjaaja / tarkastaja: Nastola 10.10.2014 Lisätiedot Proseduraaliset eli prosesseja tutkivan toiminnan menetelmät
Proseduraaliset eli prosesseja tutkivan toiminnan menetelmät 1 Mikä on prosessi? Prosessi on jokin tapahtumasarja, joka alkaa jostakin ja päätyy johonkin. Siinä voi olla (ja yleensä onkin) toimijoita, Lisätiedot Toiminnan ja prosessien mallintaminen
Irmeli Luukkonen, Juha Mykkänen, Timo Itälä, Saara Savolainen, Maarit Tamminen Toiminnan ja prosessien mallintaminen Tasot, näkökulmat ja esimerkit SOLEA-hanke Itä-Suomen yliopisto Aalto-yliopisto Irmeli Lisätiedot ESPOO 2008 VTT TIEDOTTEITA 2424. Sanna-Kaisa Ilomäki, Magnus Simons & Timo Liukko. Kohti yritysten vuorovaikutteista kehitystoimintaa
ESPOO 2008 VTT TIEDOTTEITA 2424 Sanna-Kaisa Ilomäki, Magnus Simons & Timo Liukko Kohti yritysten vuorovaikutteista kehitystoimintaa VTT TIEDOTTEITA RESEARCH NOTES 2424 Kohti yritysten vuorovaikutteista Lisätiedot Erilaisia tapoja tehdä ohjelmistokehitystä eli miten luoda ketteryyttä ja ennakkosuunnittelua oikeisiin paikkoihin
Matti Vuori Erilaisia tapoja tehdä ohjelmistokehitystä eli miten luoda ketteryyttä ja ennakkosuunnittelua oikeisiin paikkoihin Johdanto Kun esimerkiksi ohjelmistokehityksen projektimalleja kritisoidaan, Lisätiedot (ETA:n kannalta merkityksellinen teksti)
10.12.2010 Euroopan unionin virallinen lehti L 326/11 KOMISSION ASETUS (EU) N:o 1158/2010, annettu 9 päivänä joulukuuta 2010, yhteisestä turvallisuusmenetelmästä rautateiden turvallisuustodistusten saamista Lisätiedot Johdatus ohjelmistotuotantoon
Johdatus ohjelmistotuotantoon Luento nro 3, 8.9.2014 Kari Systä 8.9.2014 JOTU/K.Systä 1 Viikkoharjoitusryhmät Tiistai klo 10-12 ilm. 22/28, oli 16. Tiistai klo 12-14 ilm. 28/28, oli 21. Keskiviikko klo Lisätiedot YLE-UUTISPALVELUN ARVIOINTISUUNNITELMA
YLE-UUTISPALVELUN ARVIOINTISUUNNITELMA ( http://yle.fi/uutiset/) 01.10.2013 Verkkopalvelun laadukkuus ja arviointi MAT 81100 Tampereen teknillinen yliopisto Pekka Laaksonen Juho Ylikojola Marjaana Putro Lisätiedot VTT WORKING PAPERS 137. Eija Kupi, Jaana Keränen ja Marinka Lanne. Riskienhallinta osana pk-yritysten strategista johtamista
VTT WORKING PAPERS 137 Eija Kupi, Jaana Keränen ja Marinka Lanne Riskienhallinta osana pk-yritysten strategista johtamista ISBN 978-951-38-7476-6 (URL: http://www.vtt.fi/publications/index.jsp) ISSN 1459-7683 Lisätiedot Peppi projekti: Selvitys lukujärjestyksien suunnittelutyökaluista. Versio 0.9 17.6.2011
Peppi projekti: Selvitys lukujärjestyksien suunnittelutyökaluista Versio 0.9 17.6.2011 Sisältö 1. Johdanto... 1 1.1 Tavoitteet... 1 1.2 Rajaukset... 1 1.3 Taustaa... 1 2. Työ- ja lukujärjestyssuunnittelutyökalut... Lisätiedot LIIKETOIMINTA- PROSESSIEN KEHITTÄMINEN