ORVOSI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE PEMS BEÁGYAZOTT SZOFTERÉNEK FEJLESZTÉSE
|
|
- Artúr Gulyás
- 5 évvel ezelőtt
- Látták:
Átírás
1 ORVOSI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE PEMS BEÁGYAZOTT SZOFTERÉNEK FEJLESZTÉSE Golarits István Budapest, 22 November 2018
2 TARTALOM BEVEZETÉS PEMS FOGALMA PEMS FEJLESZTÉSI CIKLUS SW HELYE SW RISK MANAGEMENT SW DEVELOPMENT SW MAINTENANCE SW CONFIGURATION MANAGEMENT SW PROBLEM RESOLUTION
3 Mai téma PEMS = Programmable Electrical Medical System Szabvány: ANSI/AAMI/IEC Medical Device Software Software life cycle processes Miért van rá szükség? Cél? B. Braun Medical 3
4 KÖVETEL Orvostechnikai eszköz menedzsment szabványok ISO14971 ISO13485 BEFOLYÁSOL Kijelöli az orvostechnikai eszköz fejlesztés alapjait BEFOLYÁSOL IEC 62304:2006 Figure C.1 Orvostechnikai eszköz termék szabványok IEC Orvostechnikai eszköz folyamat szabvány IEC BEFOLYÁSOL Orvostechnikai eszköz szoftver Specifikus iránymutatást ad a biztonságos orvostechnikai eszköz készítéséhez Részletes irányelvet nyújt hogyan kell biztonságos szoftver rendszert fejleszteni és karbantartani Egyéb információ források IEC/ISO IEC IEC/ISO INSPIRÁL Kiegészítő irányelvek, technikák, stb. amik hasznosak lehetnek B. Braun Medical 4
5 PEMS és PESS fogalma (Komplexitás) Programmable electrical medical system PEMS Programozható gyógyászati villamos rendszer (PEMS) Olyan gyógyászati villamos készülék vagy gyógyászati villamos rendszer, amely egy vagy több programozható elektronikus alrendszert tartalmaz Programmable electronic subsystem PESS Programozható elektronikus alrendszer (PESS) Olyan rendszer, amely egy vagy több központi feldolgozó egységen alapul, beleértve a szoftvert és az interfészeket is. B. Braun Medical 5
6 Komplex rendszer A PEMS nagyobb alrendszerekre bontódik le, amelyek sorra olyan alrendszerekből épülnek fel, amelyek PESS-t tartalmaznak B. Braun Medical 6
7 PEMS Fejlesztési ciklus - V model (MSZ EN IEC ) B. Braun Medical 7
8 KÖVETEL Orvostechnikai eszköz menedzsment szabványok ISO14971 ISO13485 BEFOLYÁSOL Kijelöli az orvostechnikai eszköz fejlesztés alapjait BEFOLYÁSOL IEC 62304:2006 Figure C.1 Orvostechnikai eszköz termék szabványok IEC Orvostechnikai eszköz folyamat szabvány IEC BEFOLYÁSOL Orvostechnikai eszköz szoftver Specifikus iránymutatást ad a biztonságos orvostechnikai eszköz készítéséhez Részletes irányelvet nyújt hogyan kell biztonságos szoftver rendszert fejleszteni és karbantartani Egyéb információ források IEC/ISO IEC IEC/ISO INSPIRÁL Kiegészítő irányelvek, technikák, stb. amik hasznosak lehetnek B. Braun Medical 8
9 Szoftver fejlesztési szabványok fejlődése történeti visszatekintés, kapcsolat más iparágakkal IT szoftver fejlesztése (ISO 12207) Systems and software engineering Software life cycle processes [ ] Hogyan kell szoftvert fejleszteni? IT funkcionális biztonság (ISO 61508) Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements [ ] Hogyan kell biztonságkritikus rendszert/szoftvert fejleszteni? Minden biztonságkritikus iparágra vonatkoztatható: erőművek, jármű, stb. B. Braun Medical 9
10 KÖVETEL Orvostechnikai eszköz menedzsment szabványok ISO14971 ISO13485 BEFOLYÁSOL Kijelöli az orvostechnikai eszköz fejlesztés alapjait BEFOLYÁSOL IEC 62304:2006 Figure C.1 Orvostechnikai eszköz termék szabványok IEC Orvostechnikai eszköz folyamat szabvány IEC BEFOLYÁSOL Orvostechnikai eszköz szoftver Specifikus iránymutatást ad a biztonságos orvostechnikai eszköz készítéséhez Részletes irányelvet nyújt hogyan kell biztonságos szoftver rendszert fejleszteni és karbantartani Egyéb információ források IEC/ISO IEC IEC/ISO INSPIRÁL Kiegészítő irányelvek, technikák, stb. amik hasznosak lehetnek B. Braun Medical 10
11 Connection between and B. Braun Medical 11
12 IEC Medical Device Software Software Life-cycle processes Megfelelőség = Az összes definiált folyamat, aktivitás és feladat implementálása, a biztonsági osztálynak megfelelően. Receptkönyv a biztonságos szoftverhez. Nem létezik olyan módszer amivel egy szoftverre nézve 100%-os biztonságosság garantálható. Három elv ami a biztonságot elősegíti kockázat-irányítás, minőségirányítás és szoftverfejlesztési gyakorlatok, technikák, módszerek (state-of-the-art). A SW életciklus modell nem definiált. Lehet pl. vízesés (szekvenciális), inkrementális vagy fejlődéses (a követelmények is változnak). B. Braun Medical 12
13 Szoftverfejlesztési FOLYAMATOK és AKTIVITÁSOK áttekintése B. Braun Medical 13
14 PÉLDA: Logikai kapcsolat a folyamatok között (SOPs/Ops) Usability Eng. Active Medical Device Dev. Plan System Engineering SDP (1)(2)(3) Software Development Risk Mgmt SW Dev. SW Maint. & Prob. Res SW Config. Man. (1)SW Risk Man. (2)SW Tool Valid. Tool Test (3)SOUP (OTS) Item Valid. Medical SW Test DHF= Design History File B. Braun Medical 14 14
15 PÉLDA: aktivitások az inkrementális vagy fejlődéses modellben Mapping s activities 5.1 SW 5.1 Development 5.1 SW SW Development Planning Planning 5.1 SW Development Planning 5.2 SW 5.2 SW Requirements Requirements Analysis Analysis 5.3 SW Architectural Design 5.3 SW Architectural 5.3 SW Architectural Design Design 5.4 SW Detailed Design 5.4 SW Detailed Design SW Unit Implement. & Verif Implement. & Verification 5.6 SW Integration 5.6 SW and Integr. Testing Integration and Integr. Testing 5.7 SW System 5.7 SW Testing System Testing 5.8 SW Release into Agile s Incremental/Evolutionary life cycle For Each Story BA-HU A.Csík Medical device software Page 19 For Each Release For Each Increment For Each Project 5.2 SW Requirements Analysis High-Level, Backlog Management 5.3 SW Architectural Design Infrastructure, Spikes 5.1 SW Development Planning - Story 5.2 SW Requirements Analysis Story Details 5.3 SW Architectural Design - Emergent 5.4 SW Detailed Design 5.5 SW Unit Implementation and Verification 5.6 SW Integration and Integration Testing 5.7 SW System Testing 5.1 SW Development Planning - Project 5.1 SW Development Planning - Release 5.1 SW Development Planning - Increment B. Braun Medical 15 More stories 5.6 SW Integration and Integration Testing 5.7 SW System Testing & Regression Testing More Increments 5.6 SW Integration and Integration Testing 5.7 SW System Testing & Regression Testing 5.8 SW Release More Releases
16 Definíciók (1) Orvostechnikai eszköz szoftver (Medical Device Software) Orvostechnikai eszközbe fejlesztett szoftver vagy szándékolt alkalmazása alapján szabadon álló szoftver. Software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device in its own right. Szoftver termék (Software Product) A szoftver termék számítógép programok, eljárások, lehetséges kapcsolódó dokumentáció és adatok gyűjteménye. Software Product is set of computer programs, procedures and possibly associated documentation and data. Szoftver rendszer (Software System) A szoftver rendszer egymáshoz rendelt szoftver elemek integrált gyűjteménye, teljesíti a termékhez megfogalmazott szoftver követelmények gyűjteményét. Pl. teljes szoftver a termék részeként Software system is an integrated collection of software items organized together to accomplish a set of software requirements of a product. E.g. complete software part of a product. Megj: A PEMS modell komponenséről van szó. B. Braun Medical 16
17 Egy szoftver rendszer (62304) helye a PEMS-ben B. Braun Medical 17
18 Definíciók (2) Szoftver elem (Software Item) Szoftver elem bármilyen azonosítható számítógép program rész lehet (absztrakt). Software item is any identifiable part of a computer program Megj: Pl. a SW rendszer, egy forrás file, SOUP elemek (OS, stdlib, stb.) Szoftver egység (Software Unit) A szoftver egység az a szoftver elem, amit már nem bontunk le további elemekre. Megjegyzés: Ez felhasználható a szoftver konfiguráció menedzsmentnél és a tesztelésnél. Software unit is a software item that is not subdivided into other items. Note: It can be used for the purpose of software configuration management or testing. Megj: Pl. egy forrás file, egy task, egy objektum. SOUP (Software of Unknown Provenance) Egy már elérhető szoftver elem, amely nem az orvosi eszközbe integrálási céllal lett kifejlesztve (más szóval off-the-shelf, vagy OTS), vagy korábbi fejlesztés eredménye, amelyről nem állnak rendelkezésre a fejlesztési folyamatot kellően bizonyító dokumentumok. Software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device os software previously developed for which adequate records of development processes are not available. B. Braun Medical 18
19 SW elem és unit SW System 1 (SW Item is!) ZW 1 (SW Item is!) ZW 1 (SW Item is!) XY 1 (SW Item is!) XY n (SW Item is!) nem bontható tovább Unit 1 (SW Item is!) Unit 2 (SW Item is!) Unit n (SW Item is!) B. Braun Medical 19
20 Definíciók (3) Folyamat (Process) Összefüggő vagy kapcsolódó aktivitások halmaza, melyek bemeneteket kimenetekké konvertálnak. A set of interrelated or interacting activities that transform inputs into outputs. Aktivitás (Activity) Összefüggő vagy kapcsolódó feladatok halmaza. A set of one or more interrelated or interacting tasks. Feladat (Task) Egy darab elvégzendő munka. A single piece of work that needs to be done. Nyomon követhetőség (Traceability) A fejlesztési folyamat két vagy több terméke közötti kapcsolat mértéke. Degree to which a relationship can be established between two or more products of the development process. B. Braun Medical 20
21 IEC Medical Device Software Software Life-cycle processes Structure: 1. Scope 2. Normative References 3. Terms and Definitions 4. General Requirements 5. SW Development Process 6. SW Maintenance Process 7. SW Risk Management Process 8. SW Configuration Management Process 9. SW Problem Resolution Process B. Braun Medical 21
22 7. Szoftver kockázat-irányítási folyamat (Software Risk Management Process)! A szoftver kockázat-irányítást nem lehet az orvosi eszköz rendszerszintű kockázat-irányításától függetlenül végezni.* A szoftver kockázat-irányítást csak úgy lehet hatékonyan végezni, hogy az egyes aktivitásokat a fejlesztési és karbantartási folyamatok közben végezzük. Megj.: A kapcsolódási pontokat lásd később zölddel. Aktivitások 1. A szoftverhibából eredő veszélyes helyzeteket fel kell tárni. SW Cause? 2. A szoftvertől megkövetelt védőintézkedéseket definiálni és implementálni kell. RCM SRS 3. A szoftvertől megkövetelt védőintézkedéseket ellenőrizni kell. RCM tests 4. A szoftverváltozásokat (beleértve a SOUP-okat is) meg kell vizsgálni a lehetséges szoftverhibákból eredő veszélyes helyzetek és az implementált védőintézkedések hatékonysága tekintetében. SW changes - Risk An. (Újra vissza 1.) * Az előadásban szereplő szövegek részben a szabvány értelmezésének (ANNEX A és B) magyar nyelvű szabad fordításai. B. Braun Medical 22
23 Kockázat mátrix (Ismétlés RM) Frequent Fre Példa Likelihood Probable Occasional Remote Improbable Incredible Pro Occ Rem Imp Inc B B R A R I A N A R E Éles sarok (megvághat és zúzódást okozhat) Probability csökkentés: figyelmeztető címkét teszünk rá Severity csökkentés: lekerekítjük a sarkot, így már nem vág meg csak véraláfutást okozhat Risk Matrix for Device and Product Risk Assessments Neg Mar Sev Cri Cat Negligible Marginal Severe Critical Catastrophic Severity B. Braun Medical 23
24 Szoftver biztonsági osztályozás (1) A biztonsági osztályozás súlyosság (Severity) alapú: Negligible Software class A Marginal Software class B Severe Software class C Critical Software class C Catastrophic Software class C A biztonsági osztálynak megfelelő aktivitások/feladatok vonatkoznak az adott szoftver elemre. A biztonsági osztály csökkenthető, amennyiben a kockázatbefolyásoló - súlyosságot vagy valószínűséget csökkentő - hardveres védőintézkedésekkel a maradék kockázat elfogadható mértékűvé vált. B. Braun Medical 24
25 Szoftver biztonsági osztályozás (2) A biztonsági osztályozás öröklődő szoftver elemek között, de elkülönítéssel csökkenthető egyes alsóbb szintű elemek biztonsági osztályozása. B. Braun Medical 25
26 IEC Medical Device Software Software Life-cycle processes Structure: 1. Scope 2. Normative References 3. Terms and Definitions 4. General Requirements 5. SW Development Process 6. SW Maintenance Process 7. SW Risk Management Process 8. SW Configuration Management Process 9. SW Problem Resolution Process B. Braun Medical 26
27 5. Szoftver fejlesztési folyamat (Software Development Process) 5.1 SW development planning 5.2 SW requirements analysis 5.3 SW architectural design 5.4 SW detailed design 5.5 SW UNIT implementation & verification 5.6 SW integration and integration testing 5.7 SW system testing 5.8 SW release B. Braun Medical 27
28 5.1 Szoftver fejlesztés tervezés (Software development planning) A folyamat bemenetei lehetnek a rendszer fejlesztési terve, szabványok, munkautasítások. A kimenete pedig a szoftver fejlesztési terv. A fejlesztési tervnek ki kell térnie: az alkalmazandó folyamatokra, módszerekre, a teljesítendő feladatokra (pl. dokumentumok, szoftver verziók), a nyomon-követhetőségre, a konfiguráció- és változásirányítás folyamatára a probléma megoldás folyamatára a szoftver integrációra a szoftver verifikációra (ellenőrzés) a szoftver kockázat-irányítás folyamatára a felhasználandó vagy kifejlesztendő eszközökre B. Braun Medical 28
29 Szoftver rendszer fejlesztési életciklus modell - IEC B. Braun Medical 29
30 5.2 Szoftver követelmény analízis (Software requirements analysis) A szoftver követelmények alatt szoftver rendszer követelményeket értünk, amelyek leírandók az orvostechnikai eszköz minden szoftver rendszerére. Az aktivitás bemenete a rendszerkövetelmények (beleértve a védőintézkedéseket). Az aktivitás kimenete a szoftver követelmény specifikáció, azaz hogy MIT kell implementálni (akár papíron, akár egy bonyolult adatbázisban, pl. DOORS). A szoftver követelmények fajtái lehetnek: funkcionális, biztonsági, ki-/bemeneti, interfész, riasztást-/figyelmeztetést leíró, adatvédelmi, használhatósági, installációs, karbantartási, stb. A követelményeket ellenőrizni- (verifikálni) és ezt a tényt dokumentálni kell: A rendszer követelményeket implementálják. Nem tartalmaznak önellentmondást. Egyértelműek. Tesztelhetőek. Egyedileg azonosítottak. Nyomon követhetőek a forrásukig. Kockázat-irányítási aktivitás A biztonsággal kapcsolatos követelmények (szoftveres védőintézkedések) definiálása, ellenőrzése. B. Braun Medical 30
31 5.2 Szoftver követelmény analízis (Software requirements analysis) Példák: A felügyelő szoftver hibás működés esetén 3 másodpercen belül kapcsolja le az aktuátorok tápegységét, ezáltal biztonságos állapotba helyezve a gépet. A terápia megkezdésekor a SW figyelmeztesse a felhasználót a vérpumpa elindítására. A rendszer aktiválja a zöld lámpát kezelés közben ha a kezelés fut. Kezelés közben a SW állítsa be a felhasználó által kért vízhőmérsékletet +/-0.5C fok pontossággal. B. Braun Medical 31
32 5.3 Szoftver architektúra tervezés (Software architectural design) A szoftver architektúra tervezés tevékenység során definiáljuk a fő szerkezeti szoftver elemeket, a külsőleg látható tulajdonságaikat és a kapcsolatot közöttük. Ha egy elem viselkedése befolyásolja a többi elemet, akkor ezt a viselkedést be kell mutatni a szoftver architektúrában. Egy elem - amely hatással lehet egyéb elemekre - viselkedésének megértése (és dokumentálása) hiányában, szinte lehetetlen lesz megmutatni, hogy a rendszer biztonságos. Az aktivitás bemenete a szoftver követelmény specifikáció, kimenete az architektúra terv (csak B és C biztonsági osztályú szoftverekre). A tervnek ki kell térnie a SOUP elemre, az azok felé- és azok által támasztott követelményekre. A tervnek láttatnia kell a védőintézkedéseket megvalósító elemek elkülönülését. Az architektúra tervet ellenőrizni- (verifikálni) és ezt a tényt dokumentálni kell: A szoftver követelményeket teljes mértékben implementálja (beleértve a védőintézkedéseket). Megvalósítható, azaz tartalmazza a SW-SW és SW-HW interfészeket és definiálja a SOUP-ok környezetét. Kockázat-irányítási aktivitás Az architektúra tervezés végén áll elő a szoftver elemek teljes listája, amely bemenete a kockázatbefolyásolásnak. A megfelelő biztonsági szoftver architektúra gondos kockázatmegállapítás eredménye kell, hogy legyen. A szoftver rendszert úgy kell megtervezni, hogy egy SOUP meghibásodása esetén is megfelelő védelmet biztosítson. B. Braun Medical 32
33 PÉLDA: Szoftver architektúra tervezés Kezdeti ötlet fázistól a kész ADC (Architecture Design Chart) B. Braun Medical 33
34 Néhány szó az OTS szoftverekről (ismétlés az előző előadás anyagából) OTS = Off The Shelf vásárolt ma már egyre nagyobb arányban használt az orvosi eszköz gyártó is az alkalmazásokra koncentrálhat, melyek a speciális eszköz funkciók megvalósításához kell sok funkciója lehet, de az orvosi eszközben esetleg csak néhányat használunk az orvosi eszköz gyártó a felelős minden szoftverért, ami a készülékben van vásárlás előtt meggyőződni, hogy jó lesz az általunk kijelölt alkalmazási célra KOCKÁZAT (RISK) Az általános célra fejlesztett szoftverek nem biztos, hogy jók az orvosi eszközbe Az orvosi eszköz gyártó általánosságban feladja az OTS szoftverfejlesztési életciklus kontrollálását, de egyidejűleg felelőssége megmarad, hogy biztonságos (safe) és hatásos (effective performance) készüléket helyezzen ki a piacra OTS szoftverekre speciális, külön útmutató (FDA Guidance) B. Braun Medical 34
35 5.4 Szoftver részletes tervezés (Software detailed design) A szoftver részletes tervezési tevékenysége során finomítjuk/pontosítjuk az architektúra tervezés során meghatározott szoftver elemeket és interfészeket, hogy kialakítsuk a szoftver egységeket és azok interfészeit. Az aktivitás bemenete a szoftver architektúra terv, kimenete a részletes terv. (csak C osztályú szoftverekre.) A részletes terv specifikálja, hogy a követelményeket HOGYAN kell implementálni: algoritmusokat, adat reprezentációt, szoftver egységek közti vezérlési folyamatokat. A tervezés történhet papír alapon vagy akár CASE eszközökkel, pl. Matlab/Simulink. A részletes tervet ellenőrizni- (verifikálni) és ezt a tényt dokumentálni kell: Az architektúra tervet implementálja, azzal nincs ellentmondásban. Kockázat-irányítási aktivitás Egy szoftver elem felbontható több elemre úgy, hogy az új elemek közül csak néhány valósítja meg az eredeti elem biztonsági funkcióit. A fennmaradó elemek biztonsági osztályozása ilyen módon csökkenthető. B. Braun Medical 35
36 PÉLDA: Egyszerű infúziós pumpa SW követelmények 1. A SW a pumpát a felhasználói beállításnak megfelelően kell hogy forgassa. 2. A SW-nek aktiválnia kell a buzzert, ha a pumpa nem a beállítás szerint forog. (védőintézkedés) SW architektúra Vezérlő [B] (part [C]) OS (SOUP) [C] Ellenőrző [C] Részletes terv A vezérlő ciklikusan beolvassa a beállítást és továbbítja a pumpának az OS-en keresztül Az ellenőrző ciklikusan beolvassa a beállítást és az aktuális forgási sebességet az OS-en keresztül, valamint eltérés esetén aktiválja a buzzert (Rendszer architektúra) User Input Buzzer Vezérlő HW SW Implementáció void Vezerlo() { while(1) SetPumpSpeed(ReadSetting()); } void Ellenorzo() { while(1) { if(getpumpspeed()!= ReadSetting()) BuzzerEnable(); else BuzzerDisable(); } } Pumpa B. Braun Medical 36
37 Szoftver rendszer fejlesztési életciklus modell - IEC B. Braun Medical 37
38 5.5 Szoftver egység megvalósítás és ellenőrzés (Software unit implementation and verification) Minden szoftver egységet (unit) meg kell valósítani (implementálni), azaz forráskódra kell fordítani a meghatározott részletes tervet (manuálisan vagy kód generálással). A feladat az, hogy kódot kell írni a szoftver egységekhez és ezt ellenőrizni (verifikálni) kell. A kódolás képviseli azt a pontot, ahol a specifikáció lebontása véget ér és a futtatható szoftver előállítása elkezdődik. Az elvárt kódolási stílus eléréséhez kódolási szabályozást kell meghatározni, amely segítségével következetesen elérhető, hogy a kód a kívánatos jellemzőkkel rendelkezzen. Minden unithoz tartozó kódot verifikálni kell. A kód verifikálása során meg kell győződni arról, hogy a funkciók a részletes tervben specifikáltak alapján lettek megírva és a kódolás során a kódolási szabályozást követték. Külön elfogadási kritériumok vonatkoznak a C biztonsági osztályú szoftver elemekre. Az egység ellenőrzés eszközei lehetnek pl.: statikus kódanalizáló eszközök (Lint, QA- C, Polyspace, stb.), unit teszt, manuális kódátvizsgálás (Code Review). Kockázat-irányítási aktivitás Ebben a lépésben fontos megkülönböztetni a nem biztonságkritikus és a biztonságkritikus kódokat. A biztonságkritikus kódok ellenőrzésénél a cél, hogy a komponens hibaágra fusson és végezze el a szükséges tevékenységeket. A unit tesztelés lényege, hogy ellenőrizze, hogy a kód szándék szerint működik-e, jól meghatározott keretek között Továbbá elengedhetetlen, hogy a védőintézkedések a lehető legteljesebb mértékben legyenek kipróbálva. B. Braun Medical 38
39 PÉLDA: Szoftver egység ellenőrzési és integrációs eszköz architektúra B. Braun Medical 39
40 PÉLDA: Unit test, Static code analysis B. Braun Medical 40
41 Example of risk based Item/Unit test strategy Unit Verification In Item A In Item B In Item C Review O M M Independent review O O M Rule check M M M Basic Unit test O M M 100% Code coverage O O M Integration level test O O M M=Mandatory O=Optional Class A: No injury or damage to health is possible Class B: Non-SERIOUS INJURY is possible Class C: Death or SERIOUS INJURY is possible B. Braun Medical 41
42 Szoftver rendszer fejlesztési életciklus modell - IEC B. Braun Medical 42
43 5.6 Szoftver integráció és integrációs teszt (Software integration and integration testing) A szoftver integráció és integrációs teszt tevékenység során meg kell tervezni és végre kell hajtani a szoftver egységek (unitok) integrálását (komponensekbe) rendszerekbe és ellenőrizni (verifikálni) kell, hogy a kapott rendszer a szándékolt cél (az architektúra terv ismeretében) szerint működik. A szoftver integrációs teszt során nagy hangsúlyt kell fektetni az adatok átvitelére, a szoftver elemek belső és külső interfészeinek ellenőrzésére. A külső interfészek ellenőrzése során vizsgáljuk a kapcsolatot más szoftverekkel - ami lehet egy működő rendszer szoftver is - vagy orvostechnikai eszköz hardverrel. A szoftver integrációs teszt szimulációs környezetben, az éppen aktuális cél hardveren vagy a teljes orvostechnikai eszközön is végrehajtható. A szoftver integrációs teszt lehetőleg tartalmazzon white- és black box módszereket. Változtatások során regressziós tesztet kell végezni, demonstrálva a nem módosult részek hibamentességét (pl. automatikusan, akár naponta). Az integrációs teszt jegyzőkönyvnek tartalmaznia kell: az eredményt, elegendő információt a megismételhetőséghez, a tesztelő személyazonosságát. B. Braun Medical 43
44 5.6 Szoftver integráció és integrációs teszt - folytatás (Software integration and integration testing) A szoftver integrációs teszt során felmerülő problémák kezelésére a szoftver probléma megoldási folyamatot kell használni. A szoftver integrációs tesztet lehetséges a szoftver rendszer teszttel kombinálni. Kockázat-irányítási aktivitás Sok módszer létezik arra, hogy meggyőződhessünk arról, hogy a védőintézkedések jó eséllyel szándék szerint működnek, de egyik sem elegendő önmagában: - Statikus analízis (kód-, terv átvizsgálás (design reviews), stb.) - Dinamikus tesztelés (funkcionális-, performancia-, stressz-, használat alapú, időzítés-, memória-, stb.) - Modellezés (környezet-, időzítés szimulálás, használat modellezés) Megj.: A példák ábrázolva a következő oldalon. B. Braun Medical 44
45 B. Braun Medical 45
46 5.7 Szoftver rendszer tesztelés (Software system testing) A szoftver rendszer tesztelés során meg kell győződni arról, hogy a szoftver rendszer szándékolt cél szerint működik. A szoftver rendszer akkor tekintendő teszteltnek, ha az összes szoftver követelmény és a szoftver követelmények kombinációja (ha létezik valamilyen függőség) is le van fedve. A szoftver rendszer teszt során felmerülő problémák kezelésére a szoftver probléma megoldási folyamatot kell használni. A szoftver rendszer teszt szimulációs környezetben, az éppen aktuális cél hardveren vagy a teljes orvostechnikai eszközön is végrehajtható. Az rendszer teszt jegyzőkönyvnek tartalmaznia kell: az eredményt, elegendő információt a megismételhetőséghez, a tesztelő személyazonosságát. Változtatások során regressziós tesztet kell végezni, demonstrálva a nem módosult részek hibamentességét (pl. automatikusan, akár naponta). B. Braun Medical 46
47 5.7 Szoftver rendszer tesztelés (Software system testing) - folytatás A szoftver rendszer tesztelést ellenőrizni- (verifikálni) és ezt a tényt dokumentálni kell: A felhasznált teszt eljárások megfelelőek. Az elvégzett tesztek teljes mértékben lefedik a követelményeket (beleértve a védőintézkedéseket). A teszt eredmények nyomon követhetőek a követelményekig. Minden teszt sikerrel lett végrehajtva Kockázat-irányítási aktivitás Az orvostechnikai eszköz szoftverének módosításainak analízise - biztonsági szempontból - biztosítja, hogy a változásnak ne legyen nem szándékolt mellékhatása a biztonságra, függetlenül a korábbi biztonsági osztályba (A, B, C) sorolástól. A főbb elvárások a következők: - A szoftverváltozásokat (beleértve a SOUP-okat is) meg kell vizsgálni a lehetséges szoftverhibákból eredő veszélyes helyzetek tekintetében, hogy kiderüljön szükséges-e további védőintézkedések definiálása. - A szoftverváltozások (beleértve a SOUP-okat is) hatását is meg kell vizsgálni, hogy kiderüljön meghiúsítanak-e már korábban implementált védőintézkedéseket. B. Braun Medical 47
48 PÉLDA: Szoftver rendszer tesztelés KPI (Key Performance Indicator) Kulcs teljesítménymutatók B. Braun Medical 48
49 Example of risk based requirement test strategy Req.Class Verification A B C Exploratory O O M Scripted(Req. Based) M M M Independent Review O M M M=Mandatory O=Optional Risk control measures included in reqs Class A: No injury or damage to health is possible Class B: Non-SERIOUS INJURY is possible Class C: Death or SERIOUS INJURY is possible B. Braun Medical 49
50 PÉLDA: Egyszerű infúziós pumpa SW követelmények 1. A SW a pumpát a felhasználói beállításnak megfelelően kell hogy forgassa. 2. A SW-nek aktiválnia kell a buzzert, ha a pumpa nem a beállítás szerint forog. (védőintézkedés) SW architektúra Vezérlő [B] (part [C]) OS (SOUP) [C] Ellenőrző [C] Részletes terv A vezérlő ciklikusan beolvassa a beállítást és továbbítja a pumpának az OS-en keresztül Az ellenőrző ciklikusan beolvassa a beállítást és az aktuális forgási sebességet az OS-en keresztül, valamint eltérés esetén aktiválja a buzzert (Rendszer architektúra) User Input Buzzer SW Rendszer Teszt Indítsa el az infúziót. Állítsa be az infúziós rátát 100ml/órára. Várjon egy órát. Vezérlő HW SW Ellenőrizze, hogy a pumpa 100ml folyadékot továbbított. Kössön jelgenerátort a pumpa sebességét továbbító jelkábelre és állítson be a kívánt sebességnél nagyobb sebességet. Ellenőrizze, hogy a buzzer megszólalt. Pumpa B. Braun Medical 50
51 5.8 Szoftver kiadás (Software release) A kiadandó orvostechnikai eszköz szoftver verziójával kapcsolatos minden szoftver kiadással kapcsolatos tevékenységet a megfelelő eljárást követve kell végrehajtani és a szoftver kiadást dokumentálni kell. A szoftver verifikációt a követelményekkel szemben végre kell hajtani és az eredményeket ki kell értékelni, mielőtt a szoftvert kiadnák. A szoftver kiadás lépései a következők: Biztosítani kell a verifikáció teljességét; Az ismert fennmaradó rendellenességeket dokumentálni kell; Értékelni kell a fennmaradó rendellenességeket; A kiadott verziót dokumentálni kell; Dokumentálni kell hogyan készült a kiadott szoftver; Biztosítani kell a tevékenységek és feladatok befejezettségét; Archiválni kell a szoftvert; Biztosítani kell a szoftver kiadásának megismételhetőségét; B. Braun Medical 51
52 5.8 Szoftver kiadás (Software release) - folytatás Kockázat-irányítási aktivitás Amikor a szoftver tesztelés befejeződött és az eredmények kiértékelésre kerültek, kockázatközpontú szemlélettel annak ellenőrzésére kell fókuszálni, hogy a szoftverben implementált védőintézkedések nyomon követhetőek legyenek a kockázatelemzésbeli definíciótól kezdve az azt ellenőrző tesztjegyzőkönyvig. A konfigurációirányítási terv feladata, hogy azonosítva legyen az együtt tesztelt szoftver- és hardverelem verziók sokasága. A konfigurációirányítási terv szerint a szoftvert előállító (build) környezet és az összes felhasznált eszköz is konfiguráció ellenőrzés alá kell, hogy kerüljenek. B. Braun Medical 52
53 IEC Medical Device Software Software Life-cycle processes Structure: 1. Scope 2. Normative References 3. Terms and Definitions 4. General Requirements 5. SW Development Process 6. SW Maintenance Process 7. SW Risk Management Process 8. SW Configuration Management Process 9. SW Problem Resolution Process B. Braun Medical 53
54 6. Szoftver karbantartási folyamat (Software Maintenance Process) Development process 5.1 SW development planning 5.2 SW requirements analysis 5.3 SW architectural design 5.4 SW detailed design 5.5 SW UNIT implementation & verification 5.6 SW integration and integration testing 5.7 SW system testing 5.8 SW release = Maintenance process 6.1 Establish SW maintenance plan 6.2 Problem and modification analysis 5.3 SW architectural design 5.4 SW detailed design 5.5 SW UNIT implementation & verification 5.6 SW integration and integration testing 5.7 SW system testing 5.8 SW release B. Braun Medical 54
55 6. Szoftver karbantartási folyamat (Software Maintenance Process) Szoftver karbantartási tervet kell készíteni, melynek: le kell írnia a visszajelzések kezelésének folyamatát, le kell írnia a SOUP-ok változásainak követési folyamatát, tartalmaznia kell kritériumot, hogy mikor tekintendő a visszajelzés problémának, elő kell írnia a kockázat-irányítási, konfiguráció irányítási és probléma megoldási folyamatok használatát, Egy a szoftver fejlesztési folyamatnál kisebb karbantartási folyamat kiépítése megengedett, a visszajelzésekre történő gyors reakció érdekében. Probléma és módosítás analízis aktivitás kiadott szoftver termékre nézve: A visszajelzéseket monitorozni és értékelni kell. A probléma jelentések hatásait meg kell vizsgálni a biztonságra való tekintettel, és szükség esetén módosítási kérelmet kell indítani. Probléma megoldási folyamatot kell használni. A módosítási kérelmeket analizálni kell a szervezetre, a szoftver termékre és interfészeire gyakorolt hatása tekintetében. Majd azokat engedélyeztetni kell. Az engedélyezett módosításokról értesíteni kell a felhasználókat és a felügyelő szerveket (mik a változatlan használat következményei és hogyan lehet beszerezni a módosult szoftver terméket). B. Braun Medical 55
56 IEC Medical Device Software Software Life-cycle processes Structure: 1. Scope 2. Normative References 3. Terms and Definitions 4. General Requirements 5. SW Development Process 6. SW Maintenance Process 7. SW Risk Management Process 8. SW Configuration Management Process 9. SW Problem Resolution Process B. Braun Medical 56
57 8. Szoftver konfiguráció-irányítási folyamat (Software Configuration Management Process) Biztosítani kell egy rendszert a konfigurációs elemek (szoftver elemek, SOUP-ok, dokumentumok) és verzióik egyedi azonosíthatóságára. A szoftver rendszerbeli konfigurációs elemek halmazát le kell dokumentálni, és e dokumentáció előéletét meg kell őrizni. A konfigurációs elemeket csak engedélyezett módosítási kérelem alapján szabad módosítani. A módosítás megvalósítása során azonosítani kell a megismétlendő aktivitásokat, ideértve a biztonsági osztályozásbeli változtatást is. A módosításokat ellenőrizni kell a fejlesztési- és probléma megoldási folyamatok szerint. Biztosítani kell a módosítási kérelem, az esetlegesen érintett probléma jelentés és a módosítás engedélyezésének nyomon-követhetőségét. B. Braun Medical 57
58 IEC Medical Device Software Software Life-cycle processes Structure: 1. Scope 2. Normative References 3. Terms and Definitions 4. General Requirements 5. SW Development Process 6. SW Maintenance Process 7. SW Risk Management Process 8. SW Configuration Management Process 9. SW Problem Resolution Process B. Braun Medical 58
59 9. Szoftver probléma megoldási folyamat (Software Problem Resolution Process) Aktivitások: Probléma jelentés előkészítés (kategorizálás: típus, hatály, kritikusság) A probléma okának és megoldásának felkutatása A probléma hatásainak vizsgálata, különösen a biztonságra való tekintettel Az értékelések dokumentálása Módosítási kérelem indítása Érintett felek értesítése A (!) probléma megoldása (!) a jóváhagyott módosítási kérelem alapján A módosult szoftver részek (regressziós) tesztelése A probléma megoldottságának ellenőrzése A probléma jelentés - beleértve a megoldást és az ellenőrzést - megőrzése (pl. adatbázisban) Probléma jelentések tendenciáinak analizálása B. Braun Medical 59
60 Példa: JIRA B. Braun Medical 60
61 B. Braun Medical 61
62 KÖSZÖNÖM A FIGYELMET
Orvosi eszközök gyártmányfejlesztése PEMS beágyazott szoftverének fejlesztése. Dolgos Márton Budapest,
Orvosi eszközök gyártmányfejlesztése PEMS beágyazott szoftverének fejlesztése Dolgos Márton Budapest, 2013-10-31 Bemutatkozás Dolgos Márton Okleveles villamosmérnök (2008) Bay Zoltán Alkalmazott Kutatási
RészletesebbenOrvosi eszközök gyártmányfejlesztése PEMS beágyazott szoftverének fejlesztése. Kurtán Balázs Budapest,
Orvosi eszközök gyártmányfejlesztése PEMS beágyazott szoftverének fejlesztése Kurtán Balázs balazs.kurtan@bbraun.com Budapest, 2016-11-03 Tartalom Bevezetés PEMS fogalma PEMS fejlesztési ciklus SW helye
RészletesebbenOrvosi eszközök gyártmányfejlesztése Aktív orvosi eszköz szoftver verifikálása, validálása (V&V) Dolgos Márton Budapest, 2013-11-07
Orvosi eszközök gyártmányfejlesztése Aktív orvosi eszköz szoftver verifikálása, validálása (V&V) Dolgos Márton Budapest, 2013-11-07 Bemutatkozás Dolgos Márton Okleveles villamosmérnök (2008) Bay Zoltán
RészletesebbenOrvosi eszközök gyártmányfejlesztése Szoftver Kockázatirányítás. Lukács Viktor Budapest,
Orvosi eszközök gyártmányfejlesztése Szoftver Kockázatirányítás Lukács Viktor Budapest, 2016-10-13 Tartalom Bevezetés - Szabványok Szoftver Kockázatelemzés Kockázatértékelés Szoftveres Kockázatbefolyásolás
RészletesebbenOrvostechnikai 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
RészletesebbenORVOSI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE KOCKÁZATIRÁNYÍTÁS ÉS SZOFTVER KOCKÁZATIRÁNYÍTÁS
ORVOSI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE KOCKÁZATIRÁNYÍTÁS ÉS SZOFTVER KOCKÁZATIRÁNYÍTÁS Tegzes Ferenc Budapest, 1 March 2018 Bemutatkozás Tegzes Ferenc Okl. villamosmérnök (2012) Gyakornok, 2010-2012 B.Braun
RészletesebbenORVOSTECHNIKAI 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
RészletesebbenOrvostechnikai 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,
RészletesebbenORVOSI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZ SZOFTVER VERIFIKÁLÁSA, VALIDÁLÁSA (V&V)
ORVOSI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZ SZOFTVER VERIFIKÁLÁSA, VALIDÁLÁSA (V&V) Meilinger Ákos Budapest, 08 November 2018 Bemutatkozás Meilinger Ákos Villamosmérnök BSc (2011) Villamosmérnök
RészletesebbenOrvosi eszközök gyártmányfejlesztése Aktív orvosi eszköz szoftver verifikálása, validálása (V&V) Nagy Katinka Budapest,
Orvosi eszközök gyártmányfejlesztése Aktív orvosi eszköz szoftver verifikálása, validálása (V&V) Nagy Katinka Budapest, 2016-11-24 Bemutatkozás Nagy Katinka Villamosmérnök BSc (2012) Villamosmérnök MSc
RészletesebbenVerifiká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
RészletesebbenA 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
RészletesebbenKOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA
KOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA System Design Wahl István 2019.03.26. BME FACULTY OF TRANSPORTATION ENGINEERING AND VEHICLE ENGINEERING Tartalomjegyzék Rövidítések A rendszer definiálása
RészletesebbenMIÉ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
RészletesebbenJá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
RészletesebbenORVOSTECHNIKAI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE
ORVOSTECHNIKAI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZÖK FEJLESZTÉSE - PEMS ÉLETCIKLUS MODELL Dolgos Márton Budapest, 2018-10-04 Bemutatkozás Dolgos Márton Okleveles villamosmérnök (2008) Bay
RészletesebbenOrvostechnikai eszközök gyártmányfejlesztése Aktív orvosi eszközök fejlesztése PEMS életciklus modell. Komáromi István Budapest,
Orvostechnikai eszközök gyártmányfejlesztése Aktív orvosi eszközök fejlesztése PEMS életciklus modell Komáromi István Budapest, 2016-10-20 Bemutatkozás Dolgos Márton Okleveles villamosmérnök (2008) Bay
RészletesebbenV. 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
RészletesebbenÉ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ő
RészletesebbenA szoftver tesztelés alapjai
Szoftverellenőrzési technikák A szoftver tesztelés alapjai Micskei Zoltán, Majzik István http://www.inf.mit.bme.hu/ 1 Hol tartunk a félévi anyagban? Követelményspecifikáció ellenőrzése Ellenőrzések a tervezési
RészletesebbenA 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
RészletesebbenOrvosi eszközök gyártmányfejlesztése. Információ- és rendszerbiztonság (Cybersecurity) Csík Adrien Budapest,
Orvosi eszközök gyártmányfejlesztése Információ- és rendszerbiztonság (Cybersecurity) Csík Adrien Budapest, 2016-12-08 Bemutatkozás Molnárné Csík Adrien Okleveles villamosmérnök (1985) IRCA lead auditor
RészletesebbenIntelligens 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.
RészletesebbenOrvosi eszközök gyártmányfejlesztése Aktív orvosi eszközök verifikálása, validálása (V&V) Kuzma Éva Budapest,
Orvosi eszközök gyártmányfejlesztése Aktív orvosi eszközök verifikálása, validálása (V&V) Kuzma Éva Budapest, 2013-12-05 Bemutatkozás Kuzma Éva Okleveles műszaki menedzser (BME) -2011 Minőség-és technológiamenedzsment
RészletesebbenTESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK
TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,
RészletesebbenISO/DIS MILYEN VÁLTOZÁSOKRA SZÁMÍTHATUNK?
ISO/DIS 45001 MILYEN VÁLTOZÁSOKRA SZÁMÍTHATUNK? MIÉRT KELL SZABVÁNYOS IRÁNYÍTÁSI RENDSZER? Minden 15 másodpercben meghal egy dolgozó Minden 15 másodpercben 135 dolgozó szenved balesetet 2,3 m halálos baleset
RészletesebbenSzabványok. ISO 9000, ISO 9001, ISO 9004 és más minőségirányítási szabványok SZABVÁNY CÍMEK NEMZETKÖZI EURÓPAI NEMZETI MEGJEGYZÉS
A MINŐSÉGIRÁNYÍTÁS Szabványok Szabványok 9000, 9001, 9004 és más minőségirányítási szabványok SZABVÁNY CÍMEK NEMZETKÖZI EURÓPAI NEMZETI MEGJEGYZÉS Minőségirányítási rendszerek. Alapok és szótár 9000:2005
RészletesebbenMiskolci 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,
RészletesebbenA szoftverfejlesztési folyamatok képességének mérése. Kuzma Éva Budapest,
A szoftverfejlesztési folyamatok képességének mérése Kuzma Éva Budapest, 2013-11-14 Bemutatkozás Kuzma Éva Okleveles műszaki menedzser (BME) -2011 Minőség-és technológiamenedzsment szakirány Belső minőségügyi
RészletesebbenAutó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
RészletesebbenLaborinformációs menedzsment rendszerek. validálása. Molnár Piroska Rikker Tamás (Dr. Vékes Erika NAH)
Laborinformációs menedzsment rendszerek validálása Molnár Piroska Rikker Tamás (Dr. Vékes Erika NAH) Tartalom Túl a címen 17025:2017(8) elvárásai Gondolatok a NAH-tól LIMS validálás Számoló táblák/eszközök
RészletesebbenBiztonsá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
RészletesebbenAutóipari beágyazott rendszerek. Komponens és rendszer integráció
Autóipari beágyazott rendszerek és rendszer integráció 1 Magas szintű fejlesztési folyamat SW architektúra modellezés Modell (VFB) Magas szintű modellezés komponensek portok interfészek adattípusok meghatározása
RészletesebbenModell alapú tesztelés: célok és lehetőségek
Szoftvertesztelés 2016 Konferencia Modell alapú tesztelés: célok és lehetőségek Dr. Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika
RészletesebbenSzoftverminő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
RészletesebbenOpenCL 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
Részletesebben(Teszt)automatizálás. Bevezető
(Teszt)automatizálás Bevezető Órák ( az előadások sorrendje változhat) 1. Bevezető bemutatkozás, követelmények, kérdések és válaszok 2. Előadás Unit test in general, 3. Előadás Unit test, Tools and practices,
RészletesebbenA TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK
A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR,
RészletesebbenA 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ó
RészletesebbenA CMMI alapú szoftverfejlesztési folyamat
A CMMI alapú szoftverfejlesztési folyamat Készítette: Szmetankó Gábor G-5S8 Mi a CMMI? Capability Maturity Modell Integration Folyamat fejlesztési referencia modell Bevált gyakorlatok, praktikák halmaza,
RészletesebbenSzoftverminő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,
RészletesebbenSZOFTVER TESZT AUTOMATIZÁLÁS Eszter Vezdén Budapest, 08 November 2018
SZOFTVER TESZT AUTOMATIZÁLÁS Eszter Vezdén Budapest, 08 November 2018 Bemutatkozás Vezdén Eszter Okl. villamosmérnök ( 2018 ) Szoftverfejlesztő gyakornok ( 2015 2017 ), B.Braun Medical Kft. Szoftverfejlesztő
RészletesebbenGyakorlat és házi feladat tájékoztató
Szoftverellenőrzési technikák (VIMIM148) Gyakorlat és házi feladat tájékoztató Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Szoftverellenőrzési
RészletesebbenModell 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
RészletesebbenFejleszté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
RészletesebbenSzoftverminő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
RészletesebbenSzoftverminő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ő
RészletesebbenTeszt 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
RészletesebbenHaté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
RészletesebbenAz 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
RészletesebbenNév: Neptun kód: Pontszám:
Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,
RészletesebbenIEC 61508 Basic Engineering -től a Leszerelésig
IEC 61508 Basic Engineering -től a Leszerelésig Dr. Baradits György TÜV id: TP08000105 TÜV Functional Safety Expert Safety Instrumented System BP Rotterdaam SIL4S SIL4S Presentation Presentation BGS 2011.Q4.
RészletesebbenInformá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
RészletesebbenFolyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Munkafolyamat (Workflow): azoknak a lépéseknek a sorozata,
RészletesebbenFolyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Ez vajon egy állapotgép-e? Munkafolyamat (Workflow):
RészletesebbenSzoftverminő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
RészletesebbenSzoftver 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/
RészletesebbenSzoftverfejlesztés teszteléssel
Szoftverfejlesztés teszteléssel A szoftvertesztelés úgyis a tesztelők dolga! Vagy nem csak az övék?! 2017. november 22. (c) 2017 CTL Software Kft 1 Bemutatkozás (c) 2017 CTL Software Kft 2 ELISPOT (c)
RészletesebbenTesztelési szintek Tesztautomatizálás
Integrációs és ellenőrzési technikák (VIMIA04) Tesztelési szintek Tesztautomatizálás Majzik István, Micskei Zoltán Méréstechnika és Információs Rendszerek Tanszék Budapesti Műszaki és Gazdaságtudományi
RészletesebbenESZKÖZTÁMOGATÁS A TESZTELÉSBEN
ESZKÖZTÁMOGATÁS A TESZTELÉSBEN MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA, TURISZTIKA ÉS VENDÉGLÁTÁS TERÜLETEN
RészletesebbenII. 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
RészletesebbenKOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA
KOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA Követelmény-menedzsment Wahl István 2019.02.19. BME FACULTY OF TRANSPORTATION ENGINEERING AND VEHICLE ENGINEERING Tartalomjegyzék Rövidítések A követelmény-menedzsment
RészletesebbenS01-7 Komponens alapú szoftverfejlesztés 1
S01-7 Komponens alapú szoftverfejlesztés 1 1. A szoftverfejlesztési modell fogalma. 2. A komponens és komponens modell fogalma. 3. UML kompozíciós diagram fogalma. 4. A szoftverarchitektúrák fogalma, összetevői.
RészletesebbenFejlesztési projektek menedzselése IBM Rational CLM termékekkel. Ker-Soft Kft. Kaszás Orsolya - üzleti tanácsadó
Fejlesztési projektek menedzselése IBM Rational CLM termékekkel Ker-Soft Kft. Kaszás Orsolya - üzleti tanácsadó Tartalom I. CLM termékek rövid ismertetése II. Projekt menedzsment módszertanokról III. Demo
RészletesebbenIRÁ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
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
RészletesebbenA 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
RészletesebbenAlkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese
RészletesebbenKö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
RészletesebbenUML (Unified Modelling Language)
UML (Unified Modelling Language) UML (+ Object Constraint Language) Az objektum- modellezés egy szabványa (OMG) UML A 80-as, 90-es években egyre inkább terjedő objektum-orientált analízis és tervezés (OOA&D)
RészletesebbenUnit Teszt. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Unit Teszt / 22
Unit Teszt Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 1 / 22 Tartalomjegyzék 1 Bevezetés 2 Unit Teszt 3 Példa Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 2 / 22 Szoftvertesztelés
RészletesebbenA 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
RészletesebbenA 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
RészletesebbenVerziókövető rendszerek használata a szoftverfejlesztésben
Verziókövető rendszerek használata a szoftverfejlesztésben Dezső Balázs Szakszeminárium vezető: Molnár Bálint Budapesti Corvinus Egyetem Budapest, 2009. június 24. 1 Bevezetés 2 Verziókövetőrendszerek
RészletesebbenORVOSI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AZ AKTÍV ORVOSI ESZKÖZÖK MŰSZAKI KÖVETELMÉNYEI A HARMONIZÁLT SZABVÁNYOKBAN
ORVOSI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AZ AKTÍV ORVOSI ESZKÖZÖK MŰSZAKI KÖVETELMÉNYEI A HARMONIZÁLT SZABVÁNYOKBAN Csík Adrien Budapest, 18 October 2018 Bemutatkozás Molnárné Csík Adrien Okleveles villamosmérnök
RészletesebbenModellellenőrzés a vasút automatikai rendszerek fejlesztésében. XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő
Modellellenőrzés a vasút automatikai rendszerek fejlesztésében XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő 2018.04.25-27. Tartalom 1. Formális módszerek state of the art 2. Esettanulmány
RészletesebbenSzoftver 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
RészletesebbenTESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS
TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,
RészletesebbenOrvosi eszközök gyártmányfejlesztése Az aktív orvosi eszközök műszaki követelményei a harmonizált szabványokban
Orvosi eszközök gyártmányfejlesztése Az aktív orvosi eszközök műszaki követelményei a harmonizált szabványokban Bocz Máté Budapest, 2013-10-18 Bemutatkozás Bocz Máté Okl. villamosmérnök (2009), okl. egészségügyi
RészletesebbenLaborgyakorlat 3 A modul ellenőrzése szimulációval. Dr. Oniga István
Laborgyakorlat 3 A modul ellenőrzése szimulációval Dr. Oniga István Szimuláció és verifikáció Szimulációs lehetőségek Start Ellenőrzés után Viselkedési Funkcionális Fordítás után Leképezés után Időzítési
Részletesebben1002D STRUKTÚRÁJÚ, KRITIKUS ÜZEMBIZTONSÁGÚ RENDSZER (SCS 1 ) ELEMZÉSE DISZKRÉT-DISZKRÉT MARKOV MODELLEL
Dr. Forgon Miklós mk. ezredes ZMNE olyai János Katonai Műszaki Kar Katonai Elektronikai Tanszék forgon.miklos@zmne.hu Neszveda József főiskolai docens, irányítástechnikai szakmérnök MF Kandó Villamosmérnöki
RészletesebbenA 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
RészletesebbenViczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18.
Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Két projekt Mindkettőben folyamatirányítás Eltérő követelmények Eltérő megoldások Dokumentum gyártási folyamat Üzemeltetés
RészletesebbenSpecifikáció alapú teszttervezési módszerek
Szoftverellenőrzési technikák Specifikáció alapú teszttervezési módszerek Majzik István, Micskei Zoltán http://www.inf.mit.bme.hu/ 1 Klasszikus tesztelési feladat A tesztelendő program beolvas 3 egész
RészletesebbenSzoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar
Eötvös Loránd Tudományegyetem Informatikai Kar Szoftvertechnológia 12. előadás Szoftverfejlesztési módszerek és modellek Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto A szoftver
RészletesebbenSzoftverminő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
RészletesebbenSpecifikáció alapú teszttervezési módszerek
Szoftverellenőrzési technikák Specifikáció alapú teszttervezési módszerek Majzik István, Micskei Zoltán http://www.inf.mit.bme.hu/ 1 Klasszikus tesztelési feladat A tesztelendő program beolvas 3 egész
RészletesebbenRendszermodellezés: házi feladat bemutatás
Rendszermodellezés: házi feladat bemutatás Budapest University of Technology and Economics Fault Tolerant Systems Research Group Budapest University of Technology and Economics Department of Measurement
RészletesebbenAngolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata
Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata jelentése: gyors, fürge 1990-es évek vége Változás igénye Módszertan-család
RészletesebbenÉlettartam teszteknél alkalmazott programstruktúra egy váltóvezérlő példáján keresztül
Élettartam teszteknél alkalmazott programstruktúra egy váltóvezérlő példáján keresztül 1 Tartalom Miről is lesz szó? Bosch GS-TC Automata sebességváltó TCU (Transmission Control Unit) Élettartam tesztek
RészletesebbenSzoftver ú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
RészletesebbenSzoftver min ség és menedzsment
Szoftver min ség és menedzsment 17. A szoftvermin ség modellezése. A QMIM modell. Dr. Balla Katalin Tartalom A szoftvermin ség összetev i A probléma A QMIM keret elemei statikus vonatkozásai dinamikus
RészletesebbenBevezeté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
RészletesebbenVázlat ITIL. A változás fogalma. Változások. A változás okai. A változások ellenőrzése
ITIL Változásmenedzsment (Change management) Vázlat Változás Változás-menedzsment A fogalmak értelmezése Változásmenedzsment folyamat Különféle záróértékelések A változás fogalma Változások A változás
RészletesebbenSzoftvertechnológia ellenőrző kérdések 2005
Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?
RészletesebbenProgramtervezé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ű
RészletesebbenSzoftver é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
Részletesebben8.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
RészletesebbenLétesítménygazdálkodási szabványok a klubmenedzsmentben
Létesítménygazdálkodási szabványok a klubmenedzsmentben Berta Zsolt 2011. november 9-11. Miben segítenek a szabványok? Tartalom Létesítménygazdálkodás EN szabványok Létesítménygazdálkodási szabványok A
RészletesebbenGyakorlat és házi feladat tájékoztató
Szoftver- és rendszerellenőrzés (VIMIMA01) Gyakorlat és házi feladat tájékoztató https://inf.mit.bme.hu/edu/courses/szore Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek
RészletesebbenFogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.
Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.hu. 1 Tartalom 1. BEVEZETŐ... 3 1.1 Architektúra (terv) felülvizsgálat...
Részletesebben