Életciklus fázisok a fejlesztési gyakorlatbanBudapesti Műszaki és Gazdaságtudományi Egyetem Közlekedésmérnöki és Járműmérnöki Kar Közlekedés-és Járműirányítási

Életciklus fázisok a fejlesztési gyakorlatban

A fejlesztési életciklust átfogó/támogató tevékenységek

Budapesti Műszaki és Gazdaságtudományi EgyetemKözlekedésmérnöki és Járműmérnöki Kar

Közlekedés- és Járműirányítási Tanszék

Ismétlés – Mivel fogunk foglalkozni?

• Mely életciklus fázisokról lesz szó?• Két jellemző tevékenységi kör:

• Teljes életciklust átfogó tevékenységek

• Egy-egy fázist átfogó tevékenységek

2019. 10. 14. Korszerű módszerek a közlekedésautomatikai rendszerek fejlesztésében 2



A fejlesztési életciklust átfogó, támogató tevékenységekSzemelvények: Verifikáció és validáció, Konfigurációmenedzsment, Változásmenedzsment, Minőségmenedzsment, Biztonságmenedzsment, Dokumentálás, stb.




Fejlesztés támogató tevékenységek/folyamatok

Olyan tevékenységek melyek a teljes fejlesztési életciklust átfogják.

Mindig szükség van rájuk?

• A fejlesztés céljától függ, például:• Safety kritikus fejlesztés

• Szükség van a biztonság menedzsmentre

• Egyéb kereskedelmi célú• Nincs szükség biztonság menedzsmentre

• Nem jelenthető ki egyértelműen, hogy nincs szükség rá, azonban nem feltétlenül szükséges azonos szinten, például:• EN 61508-2:2010 Annex B

• V&V tevékenységek safety és non-safety fejlesztés esetében


Végigkísér avagy végig „kísért”?



Fejlesztés támogató tevékenységek/folyamatok




Verifikáció és validáció




Verifikáció és Validáció (V&V)

„Az igazolás célja annak bemutatása, hogy az átadandó dokumentáció a meghatározott bemenetek esetén az adott fázis előírásainak minden szempontból megfelel.”

„Az érvényesítés célja, hogy igazolja, hogy a szóban forgó rendszer – fejlesztésének bármely fázisában és a telepítés után – minden szempontból megfelel a követelményeknek.”

MSZ EN 50126:2001

Verifikáció: Jól tervezem-e rendszert?

Validáció: Jó rendszert készítettem-e?


Verifikáció (igazolás) és validáció (érvényesítés) a rendszerfejlesztésben

Rendszerkövetelmények

Rendszerkövetelmények

felosztása

Tervezés és kivitelezés

Gyártás

Telepítés

Rendszer érvényesítés

Rendszer elfogadás

Validáció

(érvényesítés)

Verifikáció

(igazolás)

Verifikáció

(igazolás)

Verifikáció

(igazolás)

Verifikáció

(igazolás)

Verifikáció

(igazolás)

Verifikáció

(igazolás)

Verifikáció

(igazolás)





Verifikáció és validáció a számítástechnikában /Majzik/

Verifikáció (igazolás) Validáció (érvényesítés)

„Jól tervezem-e a rendszert?” „Jó rendszert készítettem-e?”

A fejlesztési fázisokra és az azok közötti ellenőrzések. A fejlesztés eredményének ellenőrzésére.

Fejlesztési lépések során használt tervek (modellek) és specifikációjuk közötti megfelelés ellenőrzése.

A kész rendszer és a felhasználói elvárások közötti megfelelés ellenőrzése.

Objektív folyamat formalizálható, automatizálható.Lehetnek szubjektív elvárások formalizálás, automatizálás nehézkesebb.

Hibamodell: tervezési, implementációs hibák. Hibamodell: követelmények hiányosságai is.

Nincs rá szükség, ha automatikus a leképezés a követelmény és implementáció között.

Nincs rá szükség, ha a specifikáció tökéletes (elég egyszerű).





Miért fontos?

• 1957, Kistim (6. fokozat): meglazult hűtővezeték

• 1957, Windscale (5. fokozat) grafit melegítéssel elkéstek

• 1979. Three Mile Island (5. fokozat): megszűnt a hőelvezetés

(hibás tervezés és nem megfelelő karbantartás)

• 1986, Csernobil (7. fokozat): gőzrobbanás a 4-es reaktorban

• 2003, Paks (3. fokozat): fűtőelem kötegek túlhevülése majd hideg

vízzel történő érintkezése a mosótartályban

• 2011, Fukusima (7. fokozat): földrengés (ember okozta

katasztrófának minősítették)




• Szemelvények:

• 1967. január 27. – Apollo-1: gyakorlás közben kigyulladt a kabin

• 1967. április 23. – Szojuz-1: visszatéréskor az ernyő nem nyílt ki

• 1971. június 29. – Szojuz-11: visszatéréskor megszökött a levegő

• 1986. január 28. – Challanger: az indulást követően az űrrepülőgép felrobbant

• 1996. június 4. – Ariane 5: indítást követően önmegsemmisítés (adatkonverziós hiba)

• 2003. február 1. - Columbia: az űrrepülőgép a visszatéréskor szétesett


Miért fontos?





Miért fontos?

• 1974, McDonnell Douglas DC-10: az egyik raktérajtó kinyílása

• 2000, Concorde: az előző felszálló gép egyik alkatrésze a szárnyának csapódott

• 2008, McDonnell-Douglas MD-82: hibás szárnykonfiguráció

• 2016, LaMia Airlines 2933: üzemanyaghiány, elektromos műszerek meghibásodása

• 2018, Saratov Airlines 703: három sebességmérő három különböző értéket mutatott (jegesedés)





Miért fontos?

• 1989, Ufa: kilyukadt földgázvezeték(a pálya környezetében felhalmozódott gáz felrobbant)

• 1998, Eschede: anyagkifáradás miatt eltört az egyik kocsi kerekén az acélabroncs

• 2011, Tatabánya-Tata: műszaki meghibásodás miatt nyitott ajtóval indult el a vonat + emberi mulasztás

• 2016, Belgium: biztosítóberendezési hiba miatt egy személyvonat 90 km/h-val rohant bele egy tehervonatba

• 2017, Cegléd: két szerelvény koccanása, személyvonat mozdonya meghibásodott




• Service Level Agreement (SLA)Szolgáltatási Szint Megállapodás

• a szolgáltatónak mit kell teljesítenie

• a teljesítést a megrendelő milyen minőségi kritériumok mentén fogadja el

• hogyan fogja a megrendelő ezeket a minőségi kritériumokat mérni

• ezen mért minőségi mutatókkal arányosan mekkora számlát fog a szolgáltatótól elfogadni

• Példa: paksi atomerőmű

Szolgáltatási keretszerződés1. számú melléklet, Szolgáltatás leírások


Miért fontos?




• Példa: SLA a biztonságkritikus vasúti rendszerek fejlesztésében

• „A vasúti RAMS a vasúti hatóság által biztosított szolgáltatási minőség egyik legfőbb összetevője.” (MSZ EN 50126:2001)


Miért fontos?

12 Teljesítményellenőrzés

A vasúti szolgáltatás

minősége

Egyéb tényezők RAMS

Biztonság Üzemkészség

Megbízhatóság és

Karbantarthatóság

Üzemeltetés és

Karbantartás

R: Reliability

A: Availability

M: Maintainability

S: Safety



≈ 11415 év hibamentes működés


• Biztonságintegritás szint (pl. ASIL, SIL):egy szám, amely azt a bizalmi szintet jelzi, hogy a rendszer megfelel a meghatározott biztonsági funkcióknak a rendszeres meghibásodások tekintetében

• Részletesebben lásd később, megjegyzések:1. Funkciót vizsgálunk

• Veszély gyakorisága

• Következmények súlyossága

2. Kockázat

3. THR (Tolerable Hazard Rate)

4. SIL (Safety Integrity Level)


Miért fontos? (példa folytatása)

THR/óra/funkció(Tolerálható veszélyességi ráta)

SIL

10-9 ≤ THR <10-8 4

10-8 ≤ THR <10-7 3

10-7 ≤ THR <10-6 2

10-6 ≤ THR <10-5 1

25 év élettartam alatt≈ 456 berendezésből

1-ben lesz hiba




• Nem biztonságkritikus SLA követelmény:A mobilszolgáltatónál maximum 10 perc/év hálózat kiesés fordulhat elő.

• Követelmény sértés: a hálózat kiesés meghaladt a 10 percet

• Milyen következményekkel járhat?


Miért fontos? (példa folytatása)

• Biztonságkritikus SLA követelmény:Havonta el kell végezni az XY típusú vasúti jármű fékrendszerére előírt karbantartási folyamatot.

• Követelmény sértés: a rendszeres karbantartás 3 napot késett

• Milyen következményekkel járhat?




• A meghibásodás valószínűségének elfogadható szintre csökkentése


Összefoglalva: cél a rendszerek hibamentessége

• A V&V technikák lásd az egyes életciklus fázisoknál



Konfiguráció menedzsment




Konfigurációmenedzsment

Célja

• A termékre és/vagy szolgáltatásra vonatkozó adatok kézben tartása• Költség csökkentés

• Hatékonyság növelés (pl. változtatások gyors követése)

• Stb.

• Példa: komponensek azonosítása

Szükséges, hogy tudjuk

• az eszközeink hol találhatóak,

• az eszközöknek mekkora az értéke,

• az eszközöket mire használják,

• milyen kapcsolatban van más eszközökkel,

• Stb.





• Konfiguráció menedzsment: egy adott termék/szolgáltatás összetevőinek egyedi azonosítása, ellenőrzött tárolása, módosítása és állapotjelentése a rendszer élettartama alatt

• Konfigurációs elem (configuration item): egy egység, amely a konfigurációkezelés hatásköre alá tartozik

• Például: szoftverek, SW modulok, HW elemek, dokumentáció, stb.

• Alapkonfiguráció (baseline): jóváhagyott konfigurációs információ, amely egy termék vagy szolgáltatás jellemzőit olyan időpontban határozza meg, amely referenciaként szolgál annak teljes életciklusa során végzett tevékenységekre

• Konfigurációs adatbázis (Configuration Management Database, CMDB): egy logikailag egységes adatbázis, amely tartalmazza a konfigurációs elemek adatait és a köztük lévő kapcsolatokat

• Változat (variant): egy olyan konfigurációs elem, amely egy másiktól csak kismértékben különbözik


Néhány fogalom





Konfigurációs elemek (példák)

Konfigurációs elem

Fizikai Elektronikus

Hardver Papíralapú Dokumentum Kód

calc.cSZAMOL_V0.docxPC 502-1




Baseline (példa) Mérföldkövek (példa)

Konfigurációs elemMérföldkövek

Lezártkövetelmények

Lezártarchitektúra terv

Lezártrészletes terv

Lezártmodul teszt

Lezártrendszer teszt

Véglegeselfogadás

Projekt terv 1.0 2.0 3.0 4.0 4.1 4.1

Konfigurációmenedzsment terv

1.0 2.0 3.0 4.0 4.0 4.0

Teszt terv és tesztspecifikáció

1.0 2.0 3.0 4.5 5.2 6.3

Követelményspecifikáció

1.0 1.0 1.3 1.4 1.6 1.6

Architektúra terv − 1.0 1.2 1.3 1.3 1.3

Részletes terv − − 1.0 1.2 1.3 1.3

Felhasználóikézikönyv

− − − 1.0 1.1 1.1

Alrendszer 1. − − − 1.0 1.1 1.2

Alrendszer 2. − − − 1.0 1.1 1.2

Compiler − − − 4.3 4.3 4.3

Linker − − − 7.2.5 7.2.5 7.2.6

Teljes rendszer − − − − 1.0 1.1

Kiadás − − − − − 1.0

− jelöli, hogy a konfigurációs elem nem képezte a szállítás részét.





Dokumentumok egyedi azonosítása

K. elem Funkció

PPPP_projekt vagy termék, melyre a konfigurációs elemvonatkozik

NNN dokumentum típusa

.TTTT_ fájl kiterjesztése

x verzió

.xkiadás (amíg vázlat státuszú a dokumentum betűt kell használni, kiadott változatban pedig szám)


Egyedi azonosítás (példa)

Dokumentum típusok

NNN Jelmagyarázat

URS User Requirement Specification

SRS Software Requirement Specification

HRS Hardware Requirement Specification

ADS Architectural Design Specification

DDS Detailed Design Specification

… …

MANU_SRS.DOCX_1.A



Termelés

(dinamikus)

kiadási

kérelemkonfig. elem

Audit

Használat

(statikus)

esemény

bejegyzés

igény a

tervből

jelentés

konfig. elem konfig. elem

Változás

kezelésAzonosítás

metaadat

metaadat

metaadat

változtatási kérelem

Állapot

jelentés

metaadat

módosított adatok

elem jóváhagyás

Konfiguráció

menedzsment

Tárolás



Tevékenységek áttekintése (folyamatok, bemenet, kimenet)

Metaadat: adat az adatról.

Audit: biztosítja, hogy a termék megfelel a követelményeknek, és a teljesítés teljes (a konfigurációs elem szabadon felhasználható).

Minőségbiztosítás: A konfigurációkezelés kölcsönhatásban van a minőségbiztosítással. Egy elem jóváhagyási folyamata: amely egy konfigurációs elemet a termeléstől a tárolóig kísér.

Azonosítás: célja egy konfigurációs elem metaadatinak és kapcsolatainak meghatározása.

Példa: pincér rendelések felvétele

Tárolás: célja, hogy a konfigurációs elem eltűnését, sérülését megakadályozza, a konfigurációs elem mindig megtalálható legyen.

Változás kezelés: célja, hogy megőrizzen minden a terméken/szolgáltatáson végrehajtott változtatást, lehetővé tegye a nyomon követhetőséget az előd konfigurációs elemekhez képest.





Tevékenységek áttekintése (más szemléletek)

Structured analysis anddesign technique (SADT)Lásd később: Módszertanok




Előnyök

• Használata támogatja:• Incidensfelügyeletet• Problémakezelést• Változáskezelést• Kapacitásmenedzsmentet

• Folytonos szolgáltatás• Nyomon követhetőség• Ellenőrizhetőség• Tervezhetőség:

• Új konfigurációs elem• Karbantartási szerződések

• Megtakarításokat eredményez

Nehézségek és kockázatok

• Konfigurációs elemek legalsó szintjének megválasztása kritikus• Túl alacsony: túl sok adat• Túl magas: túl kevés adat• Eredménye: többletköltség

• Támogató eszköz használata nélkül nem hatékony (időigényes)

• Pontatlanná váló adatok (hiteltelenné válás)• Bonyolult eljárások• Hiányzó menedzsment támogatás• Nem megfelelő a támogató eszköz




Változásmenedzsment






Jelentősége

• Cél a hatékonynak lenni a változékony környezetben!• Alkalmazkodni

• Iránytani

• Megvalósítani

Szervezet

F1

F2

F3

F4

A szervezetre szüntelenül ható erőhatások:

F1: politika

F2: technológia

F3: verseny

F4: vevői igények

> A szervezet környezete állandóan változik!





Folyamat Módosítási

igény

Igény

regisztrálása

Felülvizsgálat és

értékelés

Megvalósítható?

Módosítás

tervezés

Megvalósítás

Konfiguráció

menedszment

Változási napló

Változás kérelmező

értesítése és rögzítés

a változás naplóba

Stakeholderek

Projekt

manager

Változás

manager

Fejlesztő

csapat

Projekt

manager

Szakértői csapat

Projekt

manager




• A környezet által érzékelt hatások• Pénzügyi veszteségek

• Jó hírnév elvesztése• Ügyfelek elvesztése

• Jogi következmények• Stb.

• Szervezeten belüli következmények• A változtatás:

• Nem megtervezett

• Nem megfelelő

• Nem dokumentált

• A rendszer a támadásokra/kiesésekre hajlamos

• Erőforrásokkal való visszaélések(nem megtervezett munka)


A „gyenge változáskezelés” hatásai





A változásnak való ellenállás hagyma modellje

Ellenségeskedés: „Nem bírlak.”

Félelem: „Nem szeretem a célt.”

Tartalom: „Nem hiszek a célban.”

Hitelesség: „Nem értem miért ez a cél.”

Zavar: „Nem értem a célt.”




• Irányelvek, folyamatok, szabványok

• Priorizáljunk/kategorizáljunk az időparaméterek (leállás hossza, átadási határidő), a szolgáltatás típusa és a módosítás súlyossága alapján

• Szerepkörök és felelősségek definiálása, feladatok elkülönítése, kommunikáció, stb.

• Változtatási igények kezelése

• Változtatási igények elemzése• Üzleti: a siker valószínűsége, a módosítás jelentősége,

erőforrásigény, üzleti indok

• Műszaki: a rendszer függőségei, műszaki követelmények, becslések

• Változtatási igény jelentés• A változtatási igény és státuszának világossá tétele a

menedzsment előtt

• Lehetséges státuszok: azonosított, elemzett, priorizált, megvalósított, tesztelt, telepített


Hogyan csináljuk? – A változásmenedzsment gyakorlata dióhéjban

• Jóváhagyási folyamat

• A módosítási folyamat különböző fázisaihoz megfelelő jóváhagyási folyamatot dokumentáltan kell biztosítani

• Telepítés

• Folyamata a módosítás nagyságától függ: nagymértékű, közepes, jelentéktelen

• Auditálhatóság és verziókezelés biztosítása

• Változtatás eredményeinek kezelése

• Kulcsfontosságú teljesítmény indikátorok használata pl. beállításokhoz

• A változtatott rendszer/szolgáltatás figyelemmel kísérése

• Integritás ellenőrzés

• Periodikus ellenőrzések



13 Módosítás



Változtatás/módosítás végrehajtása, mint „mini életciklus”



Minőségmenedzsment





A minőség megközelítésének módjai

MINŐSÉG

Transzcendens

a minőséget nem lehet definiálni,

akkor ismerjük fel, ha látjuk

Termék alapú

a minőség meghatározott

tulajdonságok jelenléte

vagy hiánya

Szabvány alapú

a minőség a termék/szolgáltatás

azon tulajdonsága, hogy megfelel a

vonatkozó szabványok

követelményeinek

Érték alapú

meghatározott költségért meghatározott

tulajdonságú termék/szolgáltatás

nyújtása

Termelés alapú

a minőség egy adott termék/szolgáltatás

megfelelése előre meghatározott

követelményeknek

Felhasználó alapú

a minőség a vevők igényeinek/elvárásainak

a kielégítése

Minőség fogalmak

• „Megfelelés a követelményeknek.” (P. Crosby)

• „Teljes vevői megelégedettség.” (A. V. Feigenbaum)

• „Használatra való alkalmasság, a felhasználó megítélésének megfelelően.” (J. M. Juran)

• „Az a veszteség, amelyet a társadalom elszenved a termék elszállításától kezdve.” (G. Taguchi)

• „Annak a mértéke, hogy egy objektum saját jellemzőinek egy csoportja mennyire teljesíti a követelményeket.„(MSZ EN ISO 9000:2015)






Mitől függ a minőség?

F1

F2F3

F4

A minőségre ható tényezők:

F1: felhasználó

F2: szállítók

F3: folyamatok

F4: erőforrások

F5: munkatársak

F6: környezet

F5

F6

Minőség




• A MIR tartalmazza azokat a tevékenységeket, amelyekkel a szervezet azonosítja céljait és meghatározza a kívánt eredmények eléréséhez szükséges folyamatokat.

• A MIR kezeli az egymással kölcsönhatásban lévő folyamatokat, valamint azokat az erőforrásokat, amelyek szükségesek az értékteremtéshez és az eredmények megvalósításához a lényeges érdekelt felek számára.

• A MIR képessé teszi a felső vezetőséget, hogy optimalizálja az erőforrások felhasználását, figyelembe véve döntéseinek hosszú és rövid távú következményeit.

• A MIR biztosítja az eszközöket azoknak az intézkedéseknek az azonosításához, amelyek a tervezett és nem tervezett követelményekkel foglalkoznak a termékek és a szolgáltatások nyújtása során.


Minőségirányítása rendszer (MIR, MSZ EN ISO 9000:2015)




• Vevőközpontúság

• Vezetői szerepvállalás

• A munkatársak elköteleződése

• Folyamatszemléletű megközelítés

• Fejlesztés (folyamatos)

• Bizonyítékokon alapuló döntéshozatal

• Kapcsolatok kezelése


Minőségirányítási alapelvek



MinőségmenedzsmentPéldák

ISO 10012:2003 Mérésirányítási rendszerek. A mérési folyamatokra és a mérőberendezésekre vonatkozó követelmények

„A szervezetnek meg kell határoznia azokat a mérési folyamatokat és mérőberendezéseket…”

Mérőeszköz kezelés és pontosságellenőrzés folyamata(Debreceni Egyetem, 2010)

Milyen követelmények lehetnek?

• Pl.: A mérés visszavezethetősége (MSZ EN ISO 9001:2015)

• Pl.: Azonosíthatóság

• Mérőberendezés és állapota (pl. hitelesített, kalibrált)

• Mérési folyamat

• Stb.






A minőség mérése



BiztonságmenedzsmentSafety és Security




Biztonságmenedzsment – Safety

• Egy szervezetet átfogó irányítási rendszer, amely a munkahelyi biztonsági elemek kezelésére szolgál, ami magában foglalja az irányelveket, célkitűzéseket, terveket, eljárásokat, felelősségeket, stb.

• Hol használják?• Olyan iparágakban, melyek jelentős biztonsági kockázatot kezelnek

• Közlekedés (légi, vasúti, autóipari, stb.)

• Vegyipar (kőolaj, vegyszer, gyógyászat, stb.)

• Nukleáris ipar

• Stb.


Biztonságmenedzsment rendszer (SMS)




• Szisztematikus és hatékony eljárást adni

• Veszélyek azonosításához

• Kockázatok kezeléséhez

• Megvalósítás módjának elemei:

• Kockázatok azonosítása, megfelelő ellenőrzések

• Kommunikáció

• Folyamat a nem-megfelelőségek azonosítására és javítására

• Folyamatos fejlesztés

• Példa:• Forrás: Mudra


Cél

Humántényezőképzése

Kommuni-kációs terv

JUST kultúra

Kockázat-elemzés

Megelőzési terv

Fenyegetés azonosítása

Kivizsgáló-képesség

Repülés-biztonsági felelősség

(menedzsment rendszer)

Repülésbiztonsági kultúra(emberhez kötődő)

Esemény jelentés (visszajel-

zésselegyütt)

Kockázat-menedzsment(rendszer-orientált)

Repülésbiztonság-menedzsment

Repülésbiztonsági politika





Koncepció (repülés biztonság menedzsment példa kiegészítése)

Szervezet Munkahely VédelemSzemélyek

Rejtett meghibásodások útvonala

veszélyforrás

veszteség

Lyukak keletkezése:- Aktív hibák-Látenshibák

(pl. nem kielégítő tervezés)

Kultúra éskapcsolatok

Műszakitámogatottság Képzettség,

tapasztalatKommunikáció

Pl. hiányos személyzet

Pl. tapasztalatlanfejlesztők

Pl. lejárt licenszűtervezőszoftver

Pl. túl kevésinformációcsere

Reason-modell („Swiss-cheese”) SHELL-modell

Komponensek:• Szoftver (S)• Hardver (H)• Környezet (E)• Emberek (L)

Fentiek közül mindegyik jól megfogható, kivéve az embert, akit jól meg kell érteni és a rendszer többi elemét hozzá kell igazítani!

‘L’ és a többi komponens (S, H, E, L) közötti kölcsönhatások vezetnek az emberi hibához.

S

H

E

L L



Biztonságmenedzsment – SafetyPélda

European Railway Agency: SMS wheel

SMS koncepció bevezetése:

• 2008/110/EK

• 2014/88/EU

SMS rendszer elemei a kerékdiagramban:

• Tervezés

• Kivitelezés

• Üzemeltetés

Közös biztonsági módszerek

• CSM: Common Safety Methods

Az eljárások célja a biztonságmenedzsment valamennyi területének lefedése, pl.:

• Kockázatelemzés és –értékelés (következő slide!)

• Megfelelőség értékelés – biztonsági tanúsítványok

• Megfelelőség értékelés – biztonsági jóváhagyások

• Ellenőrzés

• Felügyelet




Biztonságmenedzsment – SafetyPélda (folytatás)

Kockázat menedzsment folyamat és független biztonsági értékelés (CMS-RA)

Forrás:

Explanatory note on the CSM Assessment Body referred to in Regulation (EU) N°402/2013(1) and in OTIF UTP GEN-G of 1.1.2016 (2) on the Common Safety Method (CSM) for risk assessment

2014






A menedzsment dilemma

• Erőforrás-elosztási kérdés

• Cél: egyensúly a termelés és a biztonság között (a „safety space” területén maradni)

Ha mérleg nyelve a biztonság felé hajlik: szervezet életképessége veszélybe kerül

Ha mérleg nyelve a termelés felé hajlik:hatással lehet a termék vagy szolgáltatás biztonságosságára, balesethez vezethet




• „A nagyobb biztonságintegritási szintet követelő funkciók valószínűleg csak jóval költségesebben valósíthatók meg.”(MSZ EN 50126:2001)

• Pl. Szoftver architektúra tervezésMSZ EN 50128: 2011 Annex A.3


A menedzsment dilemma kezelése (példa)

THR/óra/funkció(Tolerálható veszélyességi ráta)

SIL

10-9 ≤ THR <10-8 4

10-8 ≤ THR <10-7 3

10-7 ≤ THR <10-6 2

10-6 ≤ THR <10-5 1



Biztonságmenedzsment – Security

• Összefogja azokat az ellenőrzéseket, amelyeket a szervezetnek végre kell hajtania annak biztosítása érdekében, hogy az eszközök• bizalmas kezelését (titkosítását)

• elérhetőségét

• sértetlenségét (integritását) → INTEGRITÁSMENEDZSMENT

a fenyegetésektől és sebezhetőségektől megvédje.


Fogalma



Biztonságmenedzsment – Security


Security onion – A réteges megközelítés

• Példák:• Adatvédelem: a személyes adatok

gyűjtésének, feldolgozásának és felhasználásának korlátozásával, az érintett személyek védelmével foglalkozik. Azaz elsősorban nem az adatokat védjük, hanem azokat a személyeket, akikkel az adatok összeköthetők.

• Alkalmazás védelem: az alkalmazások biztonságának javítását célzó intézkedések összessége (pl. a biztonsági rések felfedezése, rögzítése, megelőzés, stb.)

• További részletek és példák egy későbbi előadásban… (Kritikus rendszerek fejlesztése)



IntegritásmenedzsmentMegelőzés, azonosítás, helyreállítás




Integritásmenedzsment

• Cél: a rendszer sértetlenségének biztosítása


Integritás




• A logikai hozzáférés korlátozása• Tűzfal

• IDS (Intrusion Detection System, Behatolás érzékelő rendszer)

• Stb.

• Fizikai hozzáférés korlátozása• Hozzáférési jogosultságok

• Folyamatos fizikai hozzáférés ellenőrzése(pl. szekrényajtó nyitva)

• Stb.

• Felesleges szolgáltatások megszűntetése


MEGELŐZÉS

A fizikai hozzáférés korlátozásának szintjei…




• Metaadatok monitorozása és változások keresése• Adatok létrehozás, tárolása és felügyelete• Módosítási idő, fájlméret, ellenőrzőösszeg,

stb.

• IMS (Integritás Menedzsment Szoftver) használata• A szükséges fájlok/könyvtárak beolvasását

követően monitoroz• Pl. kritikus hálózati konfiguráció, felhasználói

adatbázis fájlok, stb.• Intézkedést hajt végre, ha integráció

sérülést detektál

• IDS (Behatolás érzékelő rendszer) alapú azonosítás


AZONOSÍTÁS




1. A létrehozott adat biztonsági másolatának elkészítése, karbantartása (több példányban, többféle formátumban, több különböző HW-en, stb.)

2. A szükséges változtatások meghatározása• Pl.: kapcsolat a teljesítményellenőrzéssel (pl. MSZ EN 50126:2001 12. fázis)

• Pl.: kapcsolat a módosítási igénnyel (pl. MSZ EN 50126:2001 13. fázis)

3. A helyreállítás megvalósíthatóságának és engedélyezhetőségének meghatározása

4. Helyreállítás

• Pl.: vírusírtó működése amikor fertőzött fájlokat talál(engedélyt kér az eltávolításra)

• Pl.: Windows biztonsági mentés és visszaállítás


HELYREÁLLÍTÁS



Követelménymenedzsment






Ismétlés

• A fejlesztési filozófiák több,mint a fele követelményekkel kapcsolatos problémakörrel foglalkozott!





Életciklus fázis vagy az életciklust átfogó támogató tevékenység?

A követelmény menedzsment célja a követelmények dokumentálása, elemzése, nyomon követése, priorizálása, elfogadása (validáció), a követelmény-változások kezelése és releváns információk eljuttatása a stakeholdereknek.

Egy folyamatos tevékenység az életciklus során.

- Stakeholderek azonosítása- Követelmények azonosítása

- Elfogadási kritérium- Elfogadási folyamat

- Stb.

Lásd később: fázisok





Követelmények nyomon követése

• Honnan származik?

• Hogyan változott?

• Hogyan ellenőrizték?

• Hogyan használták fel?

• Stb.

• Előre és hátra lépegetés az életciklusban

• Követelményeknek is életciklusa van

Karbantartott

(újra felhaszn.)Közzétett

Meghatározott

VisszaigazoltAllokáltAzonosított

Nyomon

követett

EllenőrzöttElemzettValidáltPriorizált

Jóváhagyott





Példák: követelmények nyomon követése

• Nyomon követési mátrix

Business Requirement ID Technical Requirement ID Test Case ID

… … …

B15 T025 30

B16 T026 31

B17 T027 31

B18 T028 32

… … …

Alapkövetelmény

azonosítójaRelevancia

Nem

követelményként

Gyári követelmény

azonosító

I.-{2.1-K} releváns - MA11

I.-{ 4.0} releváns SAC MA10

I.-{ 5.1-K} releváns - MA11

II.-{2.1.1-K} releváns - MA01




Később:+ Teszteset azonosítóstb.

A fejlesztés kezdeti szakaszában:





Példa: követelmények nyomon követése (szemelvények)

Forrás Azonosító Követelmény

Üzemeltetői követelmény specifikáció

VII.-{3.5.1.3-K} „A berendezés legyen alkalmas legalább 5 jármű be- és kiszámlálására.”

Üzemeltető követelményelemzése

BKV2-{20}

Hiányosság példa: Nem esik szó arról, hogy a teljes rendszernek kell 5 járművet kezelnie, vagy vágányonként kell 5 járművet kezelni.Megjegyzés: áramszedő érzékelés esetén, ha két áramszedős járművek közlekednek, akkor az 5 jármű 10 áramszedő be- és kiszámlálásának igényét jelenti.

Gyári követelményrendszer VII.-{3.5.1.3-K}-B „A berendezés legyen alkalmas legalább 5 jármű be- és kiszámlálására vágányonként.”

Követelmény allokáció VII.-{3.5.1.3-K}-B Szoftver (követelmény típusa: funkcionális)

… … …





Példa (folytatás): követelmények nyomon követése (szemelvények)

VII.-{3.5.1.3-K}

BKV2-{20}

VII.-{3.5.1.3-K}-B

O-024-005

O-024-014

SM-024

O-024-005-01

O-024-005-02

O-024-005-...

SM-024-01

SM-024-02

SM-024-...

O-024-014-01

O-024-014-02

O-024-005-...

VII.-{3.5.1.3-K}-B-01

VII.-{3.5.1.3-K}-01

Modultesztelés

tesztesetei

Integrációs teszt

tesztesetei

Rendszerteszt

tesztesetei

Validációs teszt

tesztesetei

VII.-{3.5.1.3-K}-B-01

A gráfon előre és hátrafelé is közlekedhetünk:- Milyen SW funkcionális követelmények keletkeztek a BKV2-{20} követelményelemzés alapján?- Melyik volt a gyári követelmény(ek)re vezethető vissza az SM-024-02 teszteset?

A fehér színű téglalapok:-megmutatják, hogyan változott a

követelmény a fejlesztés során- Elemzés- Tervezés- Allokáció- Stb.




• Példa: raktári alkatrész készlet nyilvántartó(nem kritikus rendszer)

• Elsődleges:• Alkatrész felvétel

• Alkatrész vételezés

• Stb.

• Másodlagos:• Bejelentkezés

• Stb.

• Egyéb:• Havi jelentés készítése

• Stb.


Követelmények priorizálása (példa) – Mi fontos a felhasználónak?

• Példa: állomási berendezés(biztonságkritikus rendszer)• Elsődleges:

• Vágányút beállítás• Vágányút ellenőrzése• Vágányút oldása• Stb.

• Másodlagos:• Kezelések (pl. váltóállítás, jelző !, stb.)• Stb.

• Egyéb:• Diagnosztika (pl. naplózás)• Stb.

Mi a különbség a kettő között?

Folyamatosan szállítható a termék:a termék részeinek szállítása

a priorizálásnak megfelelően történhet.

Jellemzően egy kitűzött időpontban történik a szállítás: a termék minden részét egyben szállítják, a priorizálásnak

azonban így is lehet jelentősége… (pl. fejlesztés nyomon követése)




• Emlékeztető:• Változásmenedzsment


Váltózó követelmények Módosítási

igény

Igény

regisztrálása

Felülvizsgálat és

értékelés

Megvalósítható?

Módosítás

tervezés

Megvalósítás

Konfiguráció

menedszment

Változási napló

Változás kérelmező

értesítése és rögzítés

a változás naplóba

Stakeholderek

Projekt

manager

Változás

manager

Fejlesztő

csapat

Projekt

manager

Szakértői csapat

Projekt

manager

13 Módosítás

Milyen a követelményrendszer?

Milyen környezetben dolgozunk?Változékony?

Stabil? (Kiforrott rendszerek?)




• Cél: a meghatározott követelmények megfeleljenek az ügyfél igényeinek

• Miért fontos?• Ha nem felel meg a rendszerünk az igényeknek:

• Tovább kell dolgoznunk rajta (többlet költségek).

• Minél később derül ki, annál költségesebb

• Stb.

• A követelmények megváltozása a legkritikusabb pont:• Újra végre kell hajtanunk az elemzést, tervezést, megvalósítást

• Újra kell tesztelni

• Stb.


Követelmények validációja (ismétlés)




Mit ellenőrzünk a validáció során?

• Érvényesség: az érdekeltek által javasolt funkciókat össze kell hangolni egymással és a rendszerrel. Ezzel pl. kiderülhet, hogy van-e igény egyéb vagy többlet funkciókra, melyek eddig rejtve voltak a javasolt funkciók között.

• Konzisztencia: a követelményrendszer ellentmondásoktól mentes, vagyis ugyanazon funkciót nem írták le kétszer, esetleg másképpen.

• Teljesség: minden követelményt és korlátozást azonosítottak.

• Megvalósíthatóság: a követelmények valóban megvalósíthatóak a meglévő technológia, a költségek, stb. figyelembevétele mellett.

• Ellenőrizhetőség: a követelmények úgy vannak konstruálva, hogy képesek vagyunk hozzájuk olyan teszteket készíteni, melyekkel bizonyítható, hogy a rendszerünk megfelel a követelményeknek.

Példák

• Érvényesség és teljesség:• Rejtett funkció: kiegészítő zöld nyíl

• Korlátozásként azonosították:„A berendezéshez nyíl alakú zöld fényjelzést adó kiegészítő jelző nem kapcsolható.”

• Konzisztencia:• Általános követelmény (minden berendezésre):

„A berendezés 230 V AC 50 Hz feszültségről üzemeljen, a figyelembe veendő feszültségingadozás +10%; - 20%.”

• Specifikus követelmény (egy adott típusú berendezésre): „A berendezés legyen képes 230 VAC hálózati betáplálással üzemelni.”

• Megvalósíthatóság:• „Az adattárnak normál üzemi körülmények között min. 2 hónap eseményeit kell

tárolnia.”

• Mit jelent a normál üzemi körülmény? Milyen eseményeket kell tárolni? Minden állapotváltozást tárolni kell?

• Mekkora adattárat válasszak? Létezik akkora tár, amivel megoldható lesz a feladat?

• Ellenőrizhetőség:• „A berendezésnek a technika elvárható szintjének (state-of-the-art) megfelelő

reakcióidőkkel kell rendelkeznie.”




Dokumentálás




Dokumentálás

• Fontos vagy nem fontos? Szükséges vagy nem? Milyen szinten?


A dokumentációs dilemma



Dokumentálás

• Lassítja a folyamatokat

• Feltartóztatja a kreativitást

• Nehéz megtalálni a hatékony formáját

• Mégis mit/milyen mélységig/hogyan dokumentáljunk?• Természetes nyelv (könnyen félreérthető, többértelmű lehet, stb.)

• Grafikus leírás (rajzok, diagramok, stb.)

• Matematikai leírás (a legtöbb stakeholder számára érthetetlen)

• Példa:


Miért nem szeretjük?

Ha az érzékelőelem hibás, akkor a kimenetein mindig hibásat és foglaltat kell adnia.

A[] (BHX == 1) imply ((OUT_F == true) && (OUT_O == true))



Dokumentálás

• A munkatársaknak nem kell gondolatolvasónak lennie – A hatékonyság nő• Függetlenül a szerzőtől lehet folyatatni a munkát• Stabilitást és nyugalmat teremt (pontos/következetes folyamatleírások, stb.)• A helyes dokumentációval könnyű ellenőrizni, hogy teljesülnek a követelmények

• A betanítás/oktatás ideje és költsége csökken – A gyorsaság nő• Az új csapattag gyorsan átveszi az információkat, strukturált módon

(nem a meglévő alkalmazottak adják át ad-hoc módon)• Az információ könnyen hozzáférhető (nem egy embernek a fejében van)• Több pénzt kereshetünk - „mert az idő pénz”• Ha valami dokumentált, kevesebb ideig tart megtalálni

• A dokumentáció bizonyítja, hogy a szervezet „profi” – Kép az elkötelezettségről• A stakeholderek felé így kommunikálunk, így ezen keresztül látják, kik is vagyunk• Vezetőként a munkatársak ezen keresztül látják elköteleződésünket abban, hogy segíteni akarjuk

munkájukat


Nem szeretjük, de mégis miért fontos?



Dokumentálás

• „A berendezéshez magyar nyelvű dokumentációt kell mellékelni, amelynek az alábbi információkat kell tartalmaznia.” (BKV-VILL-1.04)• „Műszaki leírás”

• „Kezelési utasítás”

• Stb.

• MSZ EN 50128 : 2011• A.1 táblázat

• Lifecycle Issues and Documentation


… és amikor nincs mit tenni, mert előírták/ajánlották!

Planning SIL 0 SIL 1 SIL 2 SIL 3 SIL 41. Software Quality Assurance Plan HR HR HR HR HR2. Software Quality Assurance Verification Report HR HR HR HR HR3. Software Configuration Management Plan HR HR HR HR HR4. Software Verification Plan HR HR HR HR HR5. Software Validation Plan HR HR HR HR HRSoftware requirements6. Software Requirements Specification HR HR HR HR HR7. Overall Software Test Specification HR HR HR HR HR… … … … … …



Dokumentálás

• Rendszer módosítás (2010)

• Biztonságintegritási szint: SIL4


Példa: tanúsítási dokumentáció az életciklusban (részletek)

• Új rendszer (2016)

• Biztonságintegritási szint: SIL2

0

100

200

300

400

500

600

700

800

900

Old

alsz

ám [

db

]

Életciklus fázis

Dokumentációs tevékenység az életciklus fázisokban

0

100

200

300

400

500

600

700

800

900

Old

alsz

ám [

db

]

Életciklus fázis

Dokumentációs tevékenység az életciklus fázisokban



Projektmenedzsment




Projektmenedzsment

Projekt: egyszeri vállalkozás, melynek célja, hogy egyedi terméket, szolgáltatást hozzon létre.

• Egyszeri/időszakos: mindig van eleje és vége

• Egyedi: az eredmény eltér a jelenlegitől

• Fokozatos kidolgozás: kezdetben nem látható be teljes mértékben, lépések sorozata


Fogalmak, összefüggések

Fejlesztés: Olyan, a kutatásból és gyakorlati tapasztalatokból nyert, már létező tudásra támaszkodó, rendszeres munka, amelynek célja új anyagok, termékek és szerkezetek létrehozása, új eljárások, rendszerek és szolgáltatások bevezetése vagy a már létrehozottak vagy bevezetettek lényeges javítása.



Projektmenedzsment

• A csapat munkájának koordinálására (pl. tervezés, végrehajtás, ellenőrzés, stb.) szolgál a konkrét célok elérése és a meghatározott időtartamú sikerességi kritériumok teljesítése érdekében.

• Cél: adott korlátok között elérjük az összes célkitűzést

• Elsődleges korlátok (projektmenedzsment háromszög):• Hatókör• Idő• Költség• Minőség

• Másodlagos korlátok:• Ügyfél elégedettség• Kockázat• Stb.

• A projekt tevékenységek szervezésének megközelítése (lásd életciklus modellek: szekvenciális, iteratív, inkrementális, stb.)


Fogalom, cél



Projektmenedzsment

• Plan (terv): a tervezési és előrejelzési tevékenységek

• Process (folyamat): a tevékenységeket átfogó megközelítés

• People (emberek): együttműködés és kommunikáció, amely a dinamikát adja

• Power (teljesítményt): folyamatos ellenőrzés és értékelés


A projekt sikeressége – 4P és a siker háromszöge



Projektmenedzsment


A projekt életciklusa (folyamatcsoportok)

Azonosítás/definiálás:- Érdekeltek elvárásai- Projekt célok- Projekt résztvevők

felelőssége és hatásköre- Költségvetés- Ütemezés- Pénzügyi elemzés- Kockázatok, feltételezések,

korlátok

- Hatókör meghatározása- Részfeladatokra bontás- Tevékenységek meghatározása,

összefüggések tervezése- Erőforrás és időbecslés- Ütemterv és költségvetés tervezés

- Teljesítmény információk gyűjtése, feldolgozás, elemzése,érdekeltekkel való ismertetése

- változáskezelés

- Minőségbiztosítás- Projekt csapat

teljesítményértékelése

- Függő kifizetések zárása- Dokumentáció archiválása- Bérelt eszközök visszaadása- Tapasztalatok értékelése



Projektmenedzsment


PCM – Projektciklus menedzsment



Projektmenedzsment


Területek

Projektmenedzsment

Terjedelem menedzsment

csak a kitűzött projektcélok valósuljanak meg,

a projekt végrehajtása során felmerülő új vagy

megváltozó célokat azonosítása,

beépítése a projektbeKöltségmenedzsment

a költségvetés keretein belül történő végrehajtás

biztosítása, a költségtúllépés felismerése és az

esetlegesen szükséges korrekciós

tevékenységek végrehajtása


a projekt eredményeinek az elvárt és specifikált

paraméterekkel (minőséggel) történő

leszállításának biztosítása

Emberi erőforrás

menedzsment

az erőforrások optimális felhasználása,

beleértve az erőforrások képzését és

fejlesztését is

Kommunikációmenedzsment

a projektben részt vevő összes érdekelt személy

és szervezet megfelelő mennyiségű, minőségű

és rendszerességű tájékoztatása

Kockázatmenedzsment

a minőségi és mennyiségi kockázatelemzés,

elkerülési és tartaléktervek kidolgozása

Integrációmenedzsment

elemek összehangolása

Ütemezésmenedzsment

a megtervezett ütemezés

betartása

Beszerzésmenedzsment

a beszállítókkal és partnerekkel történő

együttműködés és integráció szabályozása



Projektmenedzsment


Időtávok

• Belső érintettek:• tulajdonosok,

• menedzserek,

• alkalmazottak,

• stb.

• Külső érintettek: • Mikro környezetből:

• felhasználók, vevők,

• szállítók,

• versenytársak,

• hitelezők, stb.

• Makro környezetből:• állam,

• önkormányzat,

• környezetvédő csoportok

• stb.

• Rövid távú, Közép távú, Hosszú távú

• Példa: Nemzeti közlekedési infrastruktúra-fejlesztési stratégia (2014)

Szereplők (emlékeztető)



Projektmenedzsment


Példa – Gantt diagram



Projektmenedzsment


Mérföldkövek tervezése



A fejlesztési életciklust átfogó/támogató tevékenységek


Megkarcoltuk néhánynak a felszínét…

A legtöbb tevékenységhez szerencsére vannak támogató eszközök. Lásd később.



Összefoglalás

• A teljes fejlesztési életciklus átfedő támogató tevékenységek• Verifikáció & Validáció (V&V)• Konfigurációmenedzsment• Változásmenedzsment• Minőségmenedzsment• Biztonságmenedzsment

• Safety értelemben• Security értelemben

• Integritásmenedzsment• Követelménymenedzsment• Dokumentálás• Projektmenedzsment

• Számos további támogató tevékenység létezhet a fejlesztés környezetétel és az igényektől függően!


Köszönöm a figyelmet!


Documents

Életciklus fázisok a fejlesztési gyakorlatbanBudapesti Műszaki és Gazdaságtudományi Egyetem Közlekedésmérnöki és Járműmérnöki Kar Közlekedés-és Járműirányítási