IRÁNYÍTÓ RENDSZER IRÁNYÍTANDÓ FOLYAMAT. Biztonsági funkciók Biztonsági integritás. Normál működés. Hibák elleni védettség Saját (belső) biztonság
|
|
- Léna Bartané
- 6 évvel ezelőtt
- Látták:
Átírás
1 Biztonsági funkciók Biztonsági integritás Teljes funkcionalitás Biztonsági funkciók Irányító funkciók Gyakoriság Normál működés Kockázat osztályozás Veszélyelemzés Kockázatcsökkentés Súlyosság Belső kockázat Biztonsági integritás Hibák elleni védettség Saját (belső) biztonság IRÁNYÍTANDÓ FOLYAMAT IRÁNYÍTÓ RENDSZER 1
2 A biztonsági rendszerek belső Szisztematikus hibák A rendszer létrehozása során elkövetett emberi hibák, amelyek a rendszer üzemelése során helytelen működést okoznak. Specifikációs hibák, tervezési hibák, gyártási hibák, szoftverhibák stb. Fellépési gyakoriság nem adható meg. veszélyforrásai Véletlenszerű meghibásodások A rendszer üzemelése során fellépő meghibásodások. Fellépési gyakoriságuk megadható. A fellépési gyakoriságot befolyásolja az üzemmód, környezeti hatások, túlterhelés stb. 2
3 Biztonsági integritási szintek és hibakezelés Integritás Véletlenszerű hibák elleni int. (HW) THR Eltűrhető veszélyeztetési ráta Tolerable Hazard Rate [1/h] Saját (belső) biztonság Szisztematikus integr. (SW+HW) SIL Biztonságintegritási szint Safety Integrity Level 3
4 A szisztematikus hibák elleni védelem Személyi függetlenségek ellenőrizhetőség Megfelelő módszerek alkalmazása hibaelkerülés A fejlesztési/tervezési/gyártási folyamat szabályozása életciklus modellek követhetőség, ellenőrizhetőség, áttekinthetőség 4
5 Technikák/Intézkedé sek 1. A biztonságorientált és nem biztonságorientált rendszerek szétválasztása SIL-intézkedések, példa (EN 50129) SIL 1 SIL 2 SIL 3 SIL 4 R: jól meghatározott interfészek a biztonságorientált és nem biztonságorientált rendszerek között HR 2. Grafikus leírás beleértve pl. blokkdiagramokat 3. Strukturált specifikáció HR: manuális, hierarchikus szétválasztás alfeladatokra, interfészleírások 4. Formális vagy félformális módszerek 5. Számítógéppel támogatott specifikációs eszközök R: eszközök kiválasztása bármely konkrét tervezési módszer előnyben részesítése nélkül HR: jól meghatározott interfészek a biztonságorientált és nem biztonságorientált rendszerek között és interfész-elemzés HR HR: hierarchikus szétválasztás formális módszerek alkalmazásával, automatikus konzisztencia-ellenőrzés, finomítás a funkcionális szintig R: számítógéppel támogatott R: modellorientált eljárások hierarchikus felosztással, minden objektum, kapcsolatainak, közös adatbázisának, automatikus konzisztencia-ellenőrzésének leírása 6. Ellenőrzőlisták R: előkészített ellenőrzőlisták minden biztonsági életciklusfázisra R: előkészített részletes ellenőrzőlisták minden biztonságorientált életciklusfázisra 7. Veszélynapló HR: A Veszélynaplót fel kell fektetni és karban kell tartani a rendszer teljes életciklusa során 5
6 SIL-intézkedések, példa (EN 50129) Technikák/Intézkedés ek 1. A biztonsági szervezet tagjainak képzése 2. A résztvevők személyi függetlensége 3. A biztonsági szervezet személyzetének képesítése (lásd az 1. sz. megjegyzést) 4. (lásd a megjegyzést) SIL 1 SIL 2 SIL 3 SIL 4 HR: Kezdeti képzés minden biztonságorientált tevékenységnél lásd a 6. ábrát: a függetlenség megszervezése HR: műszaki oktatás vagy elegendő tapasztalat HR: Minden biztonságorientált tevékenységgel kapcsolatban ismétlődő képzés vagy a tevékenység rendszeres teljesítése HR: magasabb szintű műszaki oktatás vagy szélesebb körű tapasztalat 6
7 Személyi függetlenség (példa) SIL 3 ÉS 4 PM DI PM OR VER, VAL ASSR ASSR DI VER VAL SIL 1 ÉS 2 ASSR DI VER, VAL SIL 0 ASSR* DI, VER, VAL Magy.: PM DI VER VAL VAL ASSR = = = = = Project Manager Tervező, megvalósító Verifikáló Validáló Asszesszor = lehet egyazon személy =lehet egyazon szervezet * =SIL0-ra csak akkor kell asszesszor, ha egy átfogó rendszer biztonságára lehet hatással 7
8 Egyszerű fejlesztési modell Ötlet (Koncepció) Fejlesztés Termék Üzemelés
9 Fejlesztési módszerek, lépések Felhasználói követelmények Funkcionális Biztonsági Előzetes veszélyelemzés Specifikáció Top-level design Részletes tervezés A modulok megvalósítása és tesztelése/verifikáció Rendszer-integráció és rendszerteszt / validáció Engedélyezés
10 Specifikáció A rendszer működésének leírása Funkciók Együttműködés más rendszerekkel Operátori kapcsolatok Biztonsági jellemzők Tervezési kényszerek Konzultációk a megbízó és a szállító között A szerződéses kapcsolat alapja A fejlesztési folyamat végén bizonyítani kell, hogy az eredmény minden tekintetben megfelel a specifikációnak (és remélhetőleg a megbízói követelményeknek)
11 Specifikáció Követelmények Követelmények dokumentációja Követelményelemzés Rendszerspecifikáció
12 Iteratív specifikációs modell Követelmények Vasúti feltétfüzet Követelményelemzés Rendszerspecifikáció Egyeztetés a megrendelővel n Elfogadva? n Követelmények változtatása? i i Gyári feltétfüzet
13 A specifikáció kialakulása Egyszerűsítés A specifikáció mérete Betanulás Növekedés Idő
14 Az ideális specifikáció tulajdonságai Korrekt Teljes (nemcsak normál körülményekre) Konzisztens (ellentmondásmentes) Féreérthetetlen (természetes nyelvek!) A természetes nyelven írt specifikációk helyességének ellenőrzése nehéz Lehetőségek Strukturált szerkezet (félformális) Formális matematikai módszerek
15 A specifikáció hibái A biztonságkritikus rendszerek egyik legnagyobb problémája a hibás specifikáció A felhasználói követelmények meg nem felelősége A specifikáció nem felel meg a felhasználói követelményeknek A specifikációs hibák gyakran csak a kész rendszer vizsgálatakor derülnek ki, amikor a hibajavítás már igen költséges
16 Hibák keletkezése és detektálása Életciklus - idő 50% 25 kdm 40% Keletkező hibák (%) Detektált hibák (%) 20 kdm 30% 20% Hibajavítás költsége hibánként (DM) 15 kdm 10 kdm 10% 5 kdm 0% 0 kdm Idő (nem lineáris)
17 Top-level design - Detailed design Magasszintű tervezés Részl. terv. Rendszerfunkciók szétbontása Hardver Szoftver Architektúrák kidolgozása (HW és SW) Modulokra bontás (hierarchikus struktúra) Modulkapcsolatok meghatározása (interfész) Meghatározni a modulok Funkcióit Biztonsági jellemzőit Lényeges SW adatsruktúrák meghatározása Követelmények lebontása az architektúra elemeire Modulok részletes tervezése A dekompozíció gyakran iteratív (szubmodulok)
18 Dekompozíció A.1 A.2 A.2.1 A.2.2 A.3 A.4 A.2.3 A A.2
19 Begin Teszt tervezés Teszt specifikáció A TESZTELÉS FOLYAMATA Tesztesetek végrehajtása Feljegyzés, értékelés Teljesség ellenőrzése End
20 Tesztelési terv A teszt-eseteket meghatározó technika megadása A tesztelési eljárás megfelelőségét értékelő módszerek A tesztelendő rendszer fejlesztését és teszttervezését végzők függetlensége A teszt-környezet A tesztelés teljességének kritériumai Teszt-esetek meghatározása A tesztelendő rendszer kezdeti állapota A bemenetek Tesztelési terv, teszt-esetek A várt válaszok
21 Rendszer integráció Progresszív integráció - hagyományos A modulok kis csoportját (minimális rendszer) tesztelik, a hibákat javítják Fokozatosan újabb modulokkal bővítenek, tesztelnek, javítanak Az egyszerű kezdés és a kis lépésekben való bővítés miatt egyszerű a hibadetektálás és a diagnózis Hátrány: A teljes rendszer jellemzői csak az integráció befejeztével vizsgálhatók - az ilyen funkciókkal kapcsolatos hibák késői, drága feltárása, javítása Big bang módszer Tesztelés csak az integráció befejeztét követően Feltételezés: a modulok kialakítása és tesztelése megfelelő volt Előny: a durva követelmény- vagy specifikációs hibák viszonylag korán kiderülnek, javításuk kevésbé költséges Hátrány: a tesztelendő rendszer bonyolultsága miatt a tesztelés feladata jóval nehezebb
22 Rendszerteszt, engedélyezés A rendszer integrációt követően A teljes rendszer megfelel a specifikációnak Dinamikus és statikus módszerek kombinációja Szimulált vagy valós környezetben Független tanúsító (az engedélyezéshez) A fejlesztés valamennyi fázisát megfelelő gondossággal és kompetenciával hajtották végre Dokumentálni kell Valamennyi munkafázist A tesztelés részleteit és eredményeit A tanúsítás folyamatát már a projekt elején tervezni kell A szabványok, irányelvek megadják az egyes fejlesztési fázisokban szükséges dokumentációk listáját
23 Fázismodell Koncepció Gyártás Rendszerspecifikáció Alkalmazási körülmények Szerelés Kockázatelemzés Rendszer validáció Rendszerkövetelmények Rendszer elfogadás Rendszerkövetelmények lebontása Üzembehelyezés Tervezés Üzemeltetés Karbantartás Módosítás Visszatérés Üzemen kívül helyezés Leszerelés
24 Követelmények Egyszerű V-modell Kész rendszer Veszély- és kockázatelemzés Tanúsítás Specifikáció Rendszer validáció Architektúra tervezés Rendszer verifikáció TOP- DOWN Modul tervezés Rendszer integráció, tesztelés BOTTOM- UP Modul gyártás, tesztelés
25 Bővített V-modell Követelmények elemzése Üzemeltetés Karbantartás Követelmények dokumentációja Rendszervalidáció tervezése Validált rendszer Rendszerspecifikálás Rendszervalidáció Rendszerspecifikáció Rendszerverifikáció tervezése Verifikált rendszer Architektúratervezés Rendszerverifikáció Rendszerterv Integrációellenőrzés tervezése Integrált rendszer Modultervezés Rendszerintegrálás Modulok terve Modulverifikáció Modulteszttervezés Tesztelt modulok Konstrukciós tervezés Kódolás Modulok
26 Bővített V-modell Többlet-információ Az egyes fázisok terméke (dokumentáció stb.) A fázisok közötti információáramlás Még ez is erősen egyszerűsített Nem mutatja az iterációkat (bonyolult lenne) Fázisokon belül Fázisok között Nem mutatja Az egyes fázisokban párhuzamosan (pl. HW+SW) és a több fázison keresztül folytatandó tevékenységeket
27 IEC biztonsági életciklus m.
28 IEC megvalósítás
29 IEC szoftver
30 61508 életciklus modell A teljes (nemcsak a fejlesztési) életciklus valamennyi tevékenysége kezdve a koncepciós fázistól mindaddig, amíg a rendszer használatra alkalmatlanná nem válik Minden fázishoz tartozik biztonsági célú tevékenység, pl. Veszély- és kockázatelemzés A fejlesztést követő fázisok is befolyásolják a biztonságot Megvalósítási módok Villamos/elektronikus/programozható technológiák Egyéb (mechanikai, hidraulikai stb.) technológiák Külső (rendszeren kívüli) kockázatcsökkentési lehetőségek A biztonság érdekében mindig a legegyszerűbbet kell választani!
31 61508 életciklus modell Párhuzamos tervezési tevékenységek a későbbi fázisok számára Ez a modell is egyszerűsített, pl. Nem mutatja az értékelési és verifikációs tevékenységeket - ezek minden fázisnál szükségesek a továbblépés előtt A modell bármely integritási szint esetén használható Az egyes fázisokban szükséges tevékenységek azonban a SIL-től függően erősen eltérhetnek
32 ISO 26262
33 ISO 26262
Közlekedési automatika Biztonságintegritás, életciklus modellek
Közlekedési automatika Biztonságintegritás, életciklus modellek Dr. Sághi Balázs diasora alapján összeállította, kiegészítette: Lövétei István Ferenc BME Közlekedés- és Járműirányítási Tanszék 2019 Tartalomjegyzék
A BIZTONSÁGINTEGRITÁS ÉS A BIZTONSÁGORIENTÁLT ALKALMAZÁSI FELTÉTELEK TELJESÍTÉSE A VASÚTI BIZTOSÍTÓBERENDEZÉSEK TERVEZÉSE ÉS LÉTREHOZÁSA SORÁN
A BIZTONSÁGINTEGRITÁS ÉS A BIZTONSÁGORIENTÁLT ALKALMAZÁSI FELTÉTELEK TELJESÍTÉSE A VASÚTI BIZTOSÍTÓBERENDEZÉSEK TERVEZÉSE ÉS LÉTREHOZÁSA SORÁN Szabó Géza Bevezetés Az előadás célja, vasúti alrendszerekre
Egyszerű fejlesztési modell
Egyszerű fejlesztési modell Ötlet (Koncepció) Fejlesztés Termék Üzemelés Fázismodell Koncepció Gyártás Rendszerspecifikáció Alkalmazási körülmények Szerelés Kockázatelemzés Rendszer validáció Rendszerkövetelmények
A fejlesztési szabványok szerepe a szoftverellenőrzésben
A fejlesztési szabványok szerepe a szoftverellenőrzésben Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Tartalomjegyzék Biztonságkritikus rendszerek A biztonságintegritási szint Az ellenőrzés
biztonságkritikus rendszerek
Kockázat, biztonság, biztonságkritikus rendszerek Dr. Sághi Balázs BME Közlekedés- és Járműirányítási Tanszék Tartalom A közlekedéssel szembeni elvárások A kockázat fogalma Kockázatcsökkentés Követelmények
Fejlesztés kockázati alapokon 2.
Fejlesztés kockázati alapokon 2. Az IEC61508 és az IEC61511 Szabó Géza Szabo.geza@mail.bme.hu 1 A blokk célja Áttekintő kép a 61508-ról és a 61511-ről, A filozófia megismertetése, Nem cél a követelmények
Orvostechnikai eszközök gyártmányfejlesztése Aktív orvosi eszközök fejlesztése PEMS V&V. Nagy Katinka
Orvostechnikai eszközök gyártmányfejlesztése Aktív orvosi eszközök fejlesztése PEMS V&V Nagy Katinka 2016-11-24 Bemutatkozás Nagy Katinka Villamosmérnök BSc (2012) Villamosmérnök MSc (2014) Rendszer tesztmérnök,
Autóipari beágyazott rendszerek. Kockázatelemzés
Autóipari beágyazott rendszerek Kockázatelemzés 1 Biztonságkritikus rendszer Beágyazott rendszer Aminek hibája Anyagi vagyont, vagy Emberéletet veszélyeztet Tipikus példák ABS, ESP, elektronikus szervokormány
ORVOSTECHNIKAI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZÖK FEJLESZTÉSE - PEMS V&V
ORVOSTECHNIKAI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZÖK FEJLESZTÉSE - PEMS V&V Nagy Katinka Budapest, 29 November 2018 Bemutatkozás Nagy Katinka Villamosmérnök BSc (2012) Villamosmérnök MSc
A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver
Biztosítóberendezések biztonságának értékelése
Žilinská univerzita v Žiline Elektrotechnická fakulta Univerzitná 1, 010 26 Žilina tel: +421 41 5133301 e mail: kris@fel.uniza.sk Téma: Biztosítóberendezések ának értékelése prof. Ing. Karol Rástočný,
Szoftver értékelés és karbantartás
Szoftver értékelés és karbantartás Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/~majzik/ Emlékeztető: Biztonsági követelmények
Az ISO Cél: funkcionális biztonság kizárva az elektromos áramütés, tűz stb. veszélyeztetések
Az ISO 26262 Alkalmazási terület sorozatgyártott, 3.500 kg-ot nem meghaladó személygépjárművek elektromos és/vagy elektronikus (E/E) komponenseket tartalmazó biztonságreleváns rendszereire. Cél: funkcionális
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,
Biztonsági folyamatirányító. rendszerek szoftvere
Biztonsági folyamatirányító rendszerek szoftvere 1 Biztonsági folyamatirányító rendszerek szoftvere Tartalom Szoftverek szerepe a folyamatirányító rendszerekben Szoftverek megbízhatósága Szoftver életciklus
Szoftver karbantartás
Szoftver karbantartás Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/~majzik/ Áttekintés Követelményspecifikálás Architektúra
Autóipari beágyazott rendszerek. Funkcionális biztonságossági koncepció
Autóipari beágyazott rendszerek Funkcionális biztonságossági koncepció 1 Funkcionális biztonsági koncepció Functional safety concept Cél A funkcionális biztonsági követelmények levezetése A biztonsági
DW 9. előadás DW tervezése, DW-projekt
DW 9. előadás DW tervezése, DW-projekt Követelmény felmérés DW séma tervezése Betöltési modul tervezése Fizikai DW tervezése OLAP felület tervezése Hardver kiépítése Implementáció Tesztelés, bevezetés
Biztonságkritikus rendszerek
Biztonságkritikus rendszerek Rendszertervezés és -integráció dr. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék BME-MIT Mik azok a biztonságkritikus
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (2) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer A szoftver-minőségbiztosítási rendszer összetevői Szoftver minőségi alapkérdések Hogyan hasznosítsuk a know-how-t
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (13) Szoftverminőségbiztosítás Szoftverminőség és formális módszerek Formális módszerek Formális módszer formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben
Közlekedési automatika Biztonsági folyamatirányító rendszerek szoftvere
Közlekedési automatika Biztonsági folyamatirányító rendszerek szoftvere Dr. Sághi Balázs diasora alapján összeállította, kiegészítette: Lövétei István Ferenc BME Közlekedés- és Járműirányítási Tanszék
Miskolci Egyetem Általános Informatikai Tanszék
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
A tesztelés feladata. Verifikáció
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2017-18/2 (2) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer A szoftver-minőségbiztosítási rendszer összetevői Minőségbiztosítási rendszer Minőség menedzsment Minőségbiztosítás
OpenCL alapú eszközök verifikációja és validációja a gyakorlatban
OpenCL alapú eszközök verifikációja és validációja a gyakorlatban Fekete Tamás 2015. December 3. Szoftver verifikáció és validáció tantárgy Áttekintés Miért és mennyire fontos a megfelelő validáció és
Megbízhatóság az informatikai rendszerekben
Megbízhatóság az informatikai rendszerekben Az információ Minden intelligens rendszer hajtóanyaga Az információ minőségi jellemzői Sértetlenség Biztonság Adatvédelem Titkosság Hitelesség Rendelkezésre
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (8) Szoftverminőségbiztosítás Szoftvertesztelési folyamat (folyt.) Szoftvertesztelési ráfordítások (Perry 1995) Tesztelésre fordítódik a projekt költségvetés 24%-a a projekt menedzsment
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (7) Szoftverminőségbiztosítás Szoftvertesztelési folyamat Szoftverek és környezet Nem egyforma a szoftverek használatához kapcsolódó kockázat Különböző kockázati szintek -> eltérő
Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve
Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Kérdő Attila, ügyvezető, INSERO Kft. EOQ MNB, Informatikai Szakosztály, HTE, ISACA 2012. május 17. Módszertanok
II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László
A kockázat alapú felülvizsgálati és karbantartási stratégia alkalmazása a MOL Rt.-nél megvalósuló Statikus Készülékek Állapot-felügyeleti Rendszerének kialakításában II. rész: a rendszer felülvizsgálati
Verifikáció és validáció Általános bevezető
Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának
A tesztelés szükségessége
A tesztelés szükségessége Veszélyek megjelenése Hardver téren az integráltsági fok növekedése Szoftver téren a milliós nagyságrendben lévő utasításszám A rendszerek teljesítményének növekedésével együtt
Megbízhatóság és biztonság. Dr. Sághi Balázs BME Közlekedés- és Járműirányítási Tanszék 2017
Megbízhatóság és biztonság Dr. Sághi Balázs BME Közlekedés- és Járműirányítási Tanszék 2017 A közlekedési rendszerekkel szemben támasztott elvárások Elvárások Biztonság Kapacitás Probléma A kapacitás növekedése
Bevezetés a programozásba
Bevezetés a programozásba A szoftverfejlesztés folyamata PPKE-ITK Tartalom A rendszer és a szoftver fogalma A szoftver, mint termék és készítésének jellegzetességei A szoftverkészítés fázisai: Az igények
A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-technológia aspektusai
30 MB INFORMATIKAI PROJEKTELLENŐR
INFORMATIKAI PROJEKTELLENŐR 30 MB DOMBORA SÁNDOR BEVEZETÉS (INFORMATIKA, INFORMATIAKI FÜGGŐSÉG, INFORMATIKAI PROJEKTEK, MÉRNÖKI ÉS INFORMATIKAI FELADATOK TALÁKOZÁSA, TECHNOLÓGIÁK) 2016. 09. 17. MMK- Informatikai
MIÉRT KELL TESZTELNI?
Unrestricted MIÉRT KELL TESZTELNI? MIÉRT KELL TESZTELNI? A termékminőség fejlesztése...hogy megtaláljuk a hibákat, mert azok ott vannak... MIÉRT KELL TESZTELNI? Hogy felderítsük, mit tud a szoftver MIÉRT
Közlekedési automatika. Dr. Sághi Balázs BME Közlekedés- és Járműirányítási Tanszék 2017
Közlekedési automatika Dr. Sághi Balázs BME Közlekedés- és Járműirányítási Tanszék 2017 A közlekedési rendszerekkel szemben támasztott elvárások Elvárások Biztonság Kapacitás Probléma A kapacitás növekedése
Teszt terv Új funkció implementációja meglévı alkalmazásba
Teszt terv Új funkció implementációja meglévı alkalmazásba Passed Informatikai Kft. www.passed.hu Farkas Gábor 2007-P-123-45-T-1-1 IIR - Test Manager course 2 Szerepkör Név Aláírás Aláírás dátuma IT Projekt
Veszélyforrások, veszélyeztetések
Veszélyforrások, veszélyeztetések 1 Biztonságkritikus folyamatok A közlekedés veszélyes üzem: személyek tárgyak a környezet biztonságát sérülések okozásával veszélyeztetheti. Példák más veszélyes folyamatokra,
A szoftverellenőrzés szerepe Alapfogalmak
A szoftverellenőrzés szerepe Alapfogalmak Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Motiváció Tartalomjegyzék Milyen minőségi igények vannak a szoftverrel szemben, és mit tud ma a szoftveripar?
Biztonságkritikus rendszerek
Biztonságkritikus rendszerek Biztonságkritikusnak nevezzük azon rendszereket, melyek hibás működése jelentős anyagi kárt okoz, vagy emberek testi épségét, életét veszélyezteti. Autóipari rendszerek esetében
Követelmény alapú minőségbiztosítás az államigazgatásban
Követelmény alapú minőségbiztosítás az államigazgatásban László István 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Témák Követelmény
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (3) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer (folyt.) Eljárások, munkautasítások Eljárás: egy adott módja valami elvégzésének részletezett tevékenységek,
DECOS Nemzeti Nap október 15. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Megfelelőség tanúsítása modell alapon Dr. Polgár Balázs polgar@mit.bme.hu Miről lesz szó? 2 Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamatok Eszközintegrációs szintek Megfelelőségtanúsítás
Szoftverfejlesztő képzés tematika oktatott modulok
Szoftverfejlesztő képzés tematika oktatott modulok 1148-06 - Szoftverfejlesztés Megtervezi és megvalósítja az adatbázisokat Kódolja az adattárolási réteget egy adatbáziskezelő nyelv használatával Programozás
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
A szoftverfejlesztés eszközei
A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Történet (hw) Lyukkártya válogató
Vasúti biztosítóberendezések megfelelőségének tanúsítása. Tarnai Géza CERTUNIV Vasúti Tanúsító és Műszaki Szakértő Kft. Bükfürdő,
Tarnai Géza CERTUNIV Vasúti Tanúsító és Műszaki Szakértő Kft. Bükfürdő, 2015. 04. 16. Igény a megfelelőség értékelésére és tanúsítására Az igény nem új keletű biztonságkritikus rendszerek esetén fokozott
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.
Architektúrák dokumentálása UML-lel Irodalom L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, Addison-Wesley, 2003 H. Störrle: UML 2, Panem, 2007 2 Szoftver architektúra (emlékeztet!)
Projectvezetők képességei
Projectvezetők képességei MOI modell Motivation ösztönzés Organisation szervezés Ideas or Innovation ötletek vagy újítás Más felosztás Probléma megoldás Vezetői öntudat Teljesítmény Befolyás, team képzés
Programrendszerek tanúsítása szoftverminőség mérése
SZEGEDI TUDOMÁNYEGYETEM Programrendszerek tanúsítása szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát
Életciklus modellek a rendszer és szoftverrendszer-fejlesztésben. SDLC System Development Life Cycle Software Development Life Cycle
Életciklus modellek a rendszer és szoftverrendszer-fejlesztésben SDLC System Development Life Cycle Software Development Life Cycle Mi az életciklus? A termék piacon való megjelenésétől a kivonásáig terjedő
Egészségügyi ágazati kataszterek fejlesztése
Egészségügyi ágazati kataszterek fejlesztése Dr. Mayer Ákos Egészségügyi Minőségfejlesztési és Kórháztechnikai Intézet Egészségügyi Minőségfejlesztési és Kórháztechnikai Intézet - 1962: Orvosi Műszerügyi
Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft.
Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft. Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft.
Informatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs
Bevezetés Projektellenőr szerepe és feladatai Informatika Informatikai függőség Informatikai projektek Mérnöki és informatikai feladatok találkozása technológiák 1 Tartalom Informatikai projektellenőr
Üzletmenet folytonosság menedzsment [BCM]
Üzletmenet folytonosság menedzsment [BCM] Üzletmenet folytonosság menedzsment Megfelelőség, kényszer? Felügyeleti előírások Belső előírások Külföldi tulajdonos előírásai Szabványok, sztenderdek, stb Tudatos
Programtervezés. Dr. Iványi Péter
Programtervezés Dr. Iványi Péter 1 A programozás lépései 2 Feladat meghatározás Feladat kiírás Mik az input adatok A megoldáshoz szükséges idő és költség Gyorsan, jót, olcsón 3 Feladat megfogalmazása Egyértelmű
Szoftver-mérés. Szoftver metrikák. Szoftver mérés
Szoftver-mérés Szoftver metrikák Szoftver mérés Szoftver jellemz! megadása numerikus értékkel Technikák, termékek, folyamatok objektív összehasonlítása Mér! szoftverek, programok CASE eszközök Kevés szabványos
A Gazdasági - Műszaki Főigazgatóság feladatai az intézményirányítás fejlesztésében
A Gazdasági - Műszaki Főigazgatóság feladatai az intézményirányítás fejlesztésében 1. Menedzsment controlling rendszer bevezetése 2. Menedzsment controlling folyamatok kockázatelemzése 3. Az AVIR-hez kapcsolódó
Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei V&V folyamatok Eszközintegrációs szintek. Megfelelőség tanúsítása modell alapon
Megfelelőség tanúsítása modell alapon Dr. Polgár Balázs polgar@mit.bme.hu Miről lesz szó? 2 Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamatok Eszközintegrációs szintek Megfelelőségtanúsítás
Szoftver újrafelhasználás
Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
Szoftver karbantartási lépések ellenőrzése
Szoftverellenőrzési technikák (vimim148) Szoftver karbantartási lépések ellenőrzése Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.inf.mit.bme.hu/
A folyamatszemlélet, a dokumentált információ és a kockázatértékelés integrálásának gyakorlati bemutatása (A szabályozás evolúciója)
A folyamatszemlélet, a dokumentált információ és a kockázatértékelés integrálásának gyakorlati bemutatása (A szabályozás evolúciója) KERTÉSZ Zoltán, GÖNDÖR Vera Óbudai Egyetem Szervezet rövid bemutatása
Funkciópont elemzés: elmélet és gyakorlat
Funkciópont elemzés: elmélet és gyakorlat Funkciópont elemzés Szoftver metrikák Funkciópont, mint metrika A funkciópont metrika alapelveinek áttekintése Bonyolultsággal korrigált funkciópont A funkciópont
Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, Személyek és szerepkörök Kitekintő: Modell, módszertan 2 Dr. Barabás
Nagy bonyolultságú rendszerek fejlesztőeszközei
Nagy bonyolultságú rendszerek fejlesztőeszközei Balogh András balogh@optxware.com A cég A BME spin-off-ja A Hibatűrő Rendszerek Kutatócsoport tagjai alapították Tisztán magánkézben Szakmai háttér Hibatűrő
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (11) Szoftverminőségbiztosítás Tesztautomatizálás A tesztelés kivitelezése Tesztelési feladatok Detektálatlan maradék hibák számának csökkentése hatásosan és hatékonyan megfelelő
TERMÉKFEJLESZTÉS (BMEGEGE MNTF)
TERVEZÉS ELMÉLET ÉS MÓDSZERTAN (BMEGEGE MGTM) TERMÉKFEJLESZTÉS (BMEGEGE MNTF) 1. Előadás Tervezési iskolák, elméletek, módszerek. A tervezési folyamat és modellezése 2010/2011 II. félév 1 / 24 Ütemterv
Információtartalom vázlata
1. Az Ön cégétől árajánlatot kértek egy üzleti portál fejlesztésére, amelynek célja egy online áruház kialakítása. Az árajánlatkérés megválaszolásához munkaértekezletet tartanak, ahol Önnek egy vázlatos
Informatikai rendszertervezés
Informatikai rendszertervezés Dr. Varró Dániel Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs
Az átállás tervezésének feladatai. Ugrás a mélyvízbe! avagy Felkészülés a rendszer átadására Raffai Mária, dr. A szervezet-átalakítás feladatai
Ugrás a mélyvízbe! avagy Felkészülés a rendszer átadására Az átállás tervezésének feladatai 1. szervezeti architektúra kialakítása, szerepek, felelősségek meghatározása 2. dokumentációk készítése: fejlesztési
Hegesztőrobot rendszerek biztonságtechnikája
Hegesztőrobot rendszerek biztonságtechnikája Dipl. Ing. Zsolt, GYŐRVÁRY Application engineer Flexman Robotics Kft. Europe 1 A hegesztő robotrendszerekre vonatkozó biztonsági előírások csoportosítása 2
Formális módszerek GM_IN003_1 Bevezetés
Formális módszerek GM_IN003_1 Formális módszerek Formális módszer! formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben nincs olyan formális eljárás, ami egy komplex rendszer minden
Járműinformatika A járműinformatikai fejlesztés
Járműinformatika A járműinformatikai fejlesztés 2016/2017. tanév, II. félév Dr. Kovács Szilveszter E-mail: szkovacs@iit.uni-miskolc.hu Informatika Intézet 107/a. Tel: (46) 565-111 / 21-07 A járműfejlesztés
Információs rendszerek Információsrendszer-fejlesztés
Információs rendszerek Információsrendszer-fejlesztés A rendszerfejlesztés életciklusa problémadefiniálás helyzetfeltárás megvalósítási tanulmány döntés a fejlesztésrıl ELEMZÉS IMPLEMENTÁCIÓ programtervezés
Orvostechnikai eszköz tesztelése DSS Unit test. Taliga Miklós BME-IIT
Orvostechnikai eszköz tesztelése DSS Unit test Taliga Miklós BME-IIT Szabványok és direktívák Orvostechnikai eszközök feladatai Objektív eredmények képzése Embernek érzékelhetetlen paraméterek mérése Sokféle
Fejlesztés kockázati alapokon
Fejlesztés kockázati alapokon Az IEC61508 és az IEC61511 Szabó Géza Szabo.geza@mail.bme.hu 1 A blokk célja Áttekintő kép a 61508-ról és a 61511-ről, A filozófia megismertetése, Nem cél a követelmények
A kockázatelemzésre és -értékelésre vonatkozó közös biztonsági módszer (CSM)
A kockázatelemzésre és -értékelésre vonatkozó közös biztonsági módszer (CSM) Thierry BREYNE, Dragan JOVICIC Európai Vasúti Ügynökség Biztonsági egység Biztonságértékelési ágazat Cím: 120 Rue Marc LEFRANCQ
Informatikai rendszertervezés
Informatikai rendszertervezés Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
A fejlesztéshez használható eszközök
A fejlesztéshez használható eszközök CASE Tools Computer Aided Software Engineering Tools 2018.12.07. Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 1 Ismétlés fejlesztési háromszög
Szoftverfejlesztési modellek
i modellek Ha egy kitűzött célt el akarunk érni, elképzeljük, megtervezzük a hozzá vezető utat. A szoftverfejlesztés esetében a cél a szoftvertermék előállítása az ehhez elvezető utat fejlesztési módszernek
Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet
Konfiguráció menedzsment bevezetési tapasztalatok Vinczellér Gábor AAM Technologies Kft. Tartalom 2 Bevezetés Tipikus konfigurációs adatbázis kialakítási projekt Adatbázis szerkezet Adatbázis feltöltés
Modellezési alapismeretek
Modellezési alapismeretek Budapesti Műszaki és Gazdaságtudományi Egyetem Hibatűrő Rendszerek Kutatócsoport Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (4) Szoftverminőségbiztosítás Biztonság kritikus szoftverek Hibatűrés Szoftver-diverzitás Biztonság, biztonságosság Mentesség azoktól a feltételektől, melyek halált, sérülést,
Autóipari beágyazott rendszerek Dr. Balogh, András
Autóipari beágyazott rendszerek Dr. Balogh, András Autóipari beágyazott rendszerek Dr. Balogh, András Publication date 2013 Szerzői jog 2013 Dr. Balogh András Szerzői jog 2013 Dunaújvárosi Főiskola Kivonat
A szoftverellenőrzés szerepe
A szoftverellenőrzés szerepe Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Motiváció Tartalomjegyzék Milyen minőségi igények vannak a szoftverrel szemben, és mit tud ma a szoftveripar? Miért
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A
PhD Értekezés. Formális módszerek alkalmazása a vasútbiztosító technikában. Sághi Balázs
PhD Értekezés Formális módszerek alkalmazása a vasútbiztosító technikában Sághi Balázs Budapest 2003 1 Budapesti M szaki és Gazdaságtudományi Egyetem Közlekedés Tudományszak PhD Értekezés Formális módszerek
Részletes szoftver tervek ellenőrzése
Részletes szoftver tervek ellenőrzése Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/~majzik/ Tartalomjegyzék A részletes
Követelmény-specifikáció készítés és ellenőrzés
Követelmény-specifikáció készítés és ellenőrzés Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/~majzik/ Tartalomjegyzék
Új dokumentálandó folyamatok, azok minimális tartalmi elvárásai
Új dokumentálandó folyamatok, azok minimális tartalmi elvárásai Dokumentált folyamattal való rendelkezés ISO/TS 16949:2009 IATF 16949:2015 Dokumentumok kezelése, Feljegyzések kezelése, Nem megfelelő termék
SW-project management
SW-project management 1 PM tárgya tervezés megfigyelés ellenőrzés emberek folyamat események 4P People (emberek) Product (termék) Process (folyamat) Project PM szintjei 3 SW előállítási folyamat bizonytalansága
Modell alapú tesztelés mobil környezetben
Modell alapú tesztelés mobil környezetben Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A terület behatárolása Testing is an activity performed
Kezelési utasítás SITRANS F M MAG 8000 & MAG 8000 CT 02/2010. SITRANS F M MAG8000 és MAG8000 CT elektromágneses áramlásmérő típusok
Kezelési utasítás 02/2010 SITRANS F M MAG 8000 & MAG 8000 CT SITRANS F M MAG8000 és MAG8000 CT elektromágneses áramlásmérő típusok 2 Általános utasítások Az üzembe helyezés során figyelembe kell venni
Szoftver architektúra tervek ellenőrzése
Szoftver architektúra tervek ellenőrzése Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/~majzik/ Tartalomjegyzék A fázis
8.3. AZ ASIC TESZTELÉSE
8.3. AZ ASIC ELÉSE Az eddigiekben a terv helyességének vizsgálatára szimulációkat javasoltunk. A VLSI eszközök (közöttük az ASIC) tesztelése egy sokrétűbb feladat. Az ASIC modellezése és a terv vizsgálata
Telephely szintű egységes téradatkezelési stratégia a téradatok biztosítására
31. Vándorgyűlés, Szekszárd 2017. július 7. Telephely szintű egységes téradatkezelési stratégia a téradatok biztosítására Németh András csoportvezető MIG RTFO Építészeti Osztály Telephely szintű egységes