A fejlesztéshez használható · Budapesti 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 Tanszék

A fejlesztéshez használható eszközök

CASE Tools – Computer Aided Software Engineering Tools

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

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

FILOZÓFIA

MÓDSZERTAN

MÓDSZER ESZKÖZÖKAUTOMATIZÁLÁS

KÖZVETLEN

MEGVALÓSÍTÁS

Ismétlés – fejlesztési háromszög

Eszközök: alkalmazások, amelyek valamilyen formában támogatják a fejlesztést (pl. tevékenységeket automatizálnak, dokumentálnak, verziókövetnek, stb.), valamint ellenőrzik és összehangolják a fejlesztők munkáját.




Általános felépítés

• CASE-szótár (dictionary, repository)• Tartalma visszatükrözi a támogatott módszertanok terjedelmét, technikáit

• Bemenet• Grafikus editor, szöveges információk megadása

• Kimenet• Riportok, dokumentáció, grafikonok stb.

• Management• Több felhasználós hozzáférés, verziókezelés, változásmenedzsment stb.

• Más eszközökkel való adatcsere biztosítása• Azonos szótárszabvány esetén egyszerű

• Generálás (kód)• Az alkalmazás hány százalékát képes generálni




Architektúra


Repository

Server

CASE tool

on the workstation

User

Central

Repository

Description

Tools

Prototyping

Tools

Graphics

Tools

Quality

Management

Tools

Decision

Support

Tools

Inquiry &

Reporting

Tools

Document

ToolsCode

Generators

Design

Generators

Security &

Version Control

Data

Sharing

Tools

House-

keeping

tools

Inputs:

- models,

- plans,

- descriptions,

- etc.

Outputs:

- reports,

- analyses,

- etc.

Checkin & Checkout

Import & Export

Knowledge



Eszközök bevezetése egy szervezetnél

• A szervezetbe való bevezetés feltételei:• Minden szempontból legyen a legmegfelelőbb

• A teljes fejlesztési csapat ismerje (képzés), elfogadja

• Vezetői elkötelezettség

• Jó projekt menedzser• A bevezetés valószínűleg projekt keretében történik -> időveszteséget okoz, amire számítani kell


35%

30%

20%

15%

Hagyományosan

kódolás

tesztelés

tervezés

elemzés

20%

15%

25%

40%

CASE eszközzel

kódolás

tesztelés

tervezés

elemzés



Példa: követelménymenedzsment eszköz kiválasztása – I.

# Követelmény csoport Kifejtés/magyarázat Prioritás

R-01 Dokumentáció generálása Hierarchikus fejezetek, exportálás fájlba, importálás fájlból, stb. 0

R-02 Webes hivatkozások, interfész Böngészőn keresztül is legyen kezelhető. 0

R-03 PillanatfelvételLegyen valamilyen snapshot jellegű funkciója (pl. a Word / Excel export is ennek számít),melynek célja, hogy az adott rögzített verzió mellé csatolni lehessen információkat. Fontos, hogy a pillanatkép feldolgozható formátumú legyen.

0

R-04 Verziókövetés - 0

R-05 NyomonkövetésA követelményváltozások kezelését időbeli struktúra és triggerek alapján képes legyen követni. Adott verzión belül értelmezett (pl. specifikáció és követelmények közötti kapcsolat legyen feltárható).

0

R-06 NavigálhatóságLegyen képes a kapcsolatokon való navigációra előre és hátra irányban is.Előre irány: hatás analízis; hátra irány: eredet analízis.

0

R-07 Relációk kezelése A követelmények nyilvántartásánál mindenféle relációt kezeljen. 1

R-08 Verifikáció menedzseléseLegyen benne rögzíthető a verifikációs terv, analízis, tesztelés, mérések, stb.A verifikáció legyen indítható a követelménykezelőből (tesztesetek futtatása).A verifikáció állapotának nyomonkövetése, rögzítése, stb.

1




Példa: követelménymenedzsment eszköz kiválasztása – II.

• Az egyes eszközök értékelésénél egyszerű kategóriák:• Teljesíti (pontszám: 2)

• Részben teljesíti (pontszám: 1)

• Nem teljesíti (pontszám: 0)


# Követelmény csoport Kifejtés/magyarázat Prioritás

R-09Nézetek, csoportosítás, keresés

Biztosítása a követelménylista különböző szempontú nézeteinek beállíthatóságát.Biztosítása a követelménylistákban különböző szempontok szerinti keresést.

1

R-10Űrlapok tulajdonságainak beállítása

Pl. legyen beállítható, hogy új követelmény felvételekor milyen adatokat kívánunk megadni.

1

R-11 Hierarchikus felépítés A követelmények nyilvántartását hierarchikus felépítés mellett végezze. 2

R-12Fedettségi listák automatikus generálása

Legyen képes fedettségi listák automatikus generálásra.Példa fedettségi listára: lefedetlen követelmények, indokolatlan megvalósítás, stb.

2

R-13 Jogosultság kezelése Kezeljen hozzáférési szinteket, különböző szerepköröket. 2

R-14 Értesítési rendszer A változásokról értesítse az érintetteket. Legyen konfigurálható az értesítési rendszer. 2

R-15 Security Sértetlenség, biztonsági másolatok, stb. 2

R-16 Megosztott szerkesztés Támogassa a csapat/csoportos munkát. 2



Milyen hasznokkal járhat egy jól kiválasztott CASE eszköz?

• Redundancia-mentes terv

• Szintaktikai hibák meghatározott részének automatikus kizárása

• Modellek konzisztenciája ellenőrizhető

• Csoportmunka támogatása

• Nyomon követhetőség

• Változáskezelés

• Automatikus kódgenerálás

• Automatikus dokumentáció generálás

• Stb.




Eszközök csoportosítása: integráltság

• Tool: legalább egy fejlesztési fázist támogat

• Toolkit: néhány fejlesztési fázist támogat

• Workbench: teljes fejlesztési életciklust támogat

• Integrated Workbench: többféle módszertant is támogat




Eszközök csoportosítása: életciklus és folyamat

Életciklus

• Upper CASE: stratégiai tervezés, projektvezetés

• Middle CASE: rendszerelemzés, tervezés

• Lower CASE: rendszerspecifikáció készítés

Folyamat


Eszköz típus Specifikáció Tervezés Megvalósítás V&V

Tesztelő X X

Nyomkövető X X

Programelemző X X

Nyelvi feldolgozó X X

Módszertámogató X X

Prototípuskészítő X X

Konfigurációkezelő X X

Változtatáskezelő X X X X

Dokumentációs X X X X

Szerkesztő X X X X

Tervező X X X X

Újratervezési X



Eszközök csoportosítása: funkcionalitás


• Tervező eszköz

• Szerkesztő eszköz

• Változáskezelő eszköz

• Konfigurációkezelő eszköz

• Prototípus készítő eszköz

• Módszertámogató eszköz

• Nyelvi feldolgozó eszköz

• Programelemző eszköz

• Tesztelő eszköz

• Nyomonkövető eszköz

• Dokumentációs eszköz

• Újratervezési eszköz

• Stb.



Fejlesztési eszközök a szabványokban (IEC 61508, EN 50128)

• T1: olyan eszköz, amelynek kimenete semmilyen formában (közvetlenül/közvetve ill. az adatokat is beleértve) sem járul hozzá a biztonságkritikus rendszer futtatható kódjához• Pl.: szövegszerkesztő editor

• T2: olyan eszköz, amely támogatja a tervezés/futtatható kód tesztelését vagy ellenőrzését (az eszköz közvetlenül nem tud hibát létrehozni a szoftverben)• Pl.: statikus elemző, teszt lefedettség mérő

• T3: olyan eszköz, melynek van olyan kimenete, amely közvetetetten vagy közvetlenül hatással van a biztonságkritikus rendszer futtatható kódjára• Pl. compiler




Fejlesztési eszközök a szabványokban (ISO 26262-8)




Fejlesztési eszközök a szabványokban (ISO 26262-8)


• Kategóriacsoport 1: egy adott szoftvereszköz észlelhet/nem észlelhet hibát a biztonság-releváns fejlesztési termékkel kapcsolatban• TI1: akkor alkalmazandó, ha van olyan bizonyíték, hogy az eszköz erre nem képes (nem kell

minősíteni)

• TI2: minden más esetben választandó (minden felhasználói esetet elemezni kell a potenciális hibákra és azok feltárására vonatkozóan)

• Kategóriacsoport 2: Tool Error Detection• TD1: a hiba felismerésének vagy megelőzésének valószínűsége magas

• TD2: a hiba felismerésének vagy megelőzésének valószínűsége közepes

• TD3: minden más esetben (alacsony vagy ismeretlen)



Fejlesztési eszközök a szabványokban (DO-178 C, DO-330)

• DO-178 C: eszközök minősítése• Kritérium 1: olyan eszköz, melynek kimenete részét képezi a (kritikus) légi szoftvernek, vagyis az

eszköz hibát okozhat a kritikus szoftverben

• Kritérium 2: olyan eszköz, amely automatizálja a verifikációs folyamatokat (azaz hibát nem észlelhet) és amelynek a kimenetét a fejlesztési- és verifikációs folyamatok megszüntetésére vagy csökkentésére használjuk fel

• Kritérium 3: olyan eszköz, amely a tervezett felhasználási körén belül hibát nem észlelhet

• Előbbi kategóriákból és a SW kockázati szintjéből jön létre a Tool Qualification Level (TQL)

• DO-330: az eszközök minősítéséhez alkalmazott folyamatok


ahol TQL-1 a legszigorúbb szint

BemutatóFejlesztési eszközök




Összefoglalás

• Eszközök felépítés

• Eszközök bevezetése egy szervezetnél

• Eszközök csoportosítása:• Integráltság

• Életciklus és folyamat

• Funkcionalitás

• Fejlesztési eszközök a szabványokban


Köszönöm a figyelmet!


Documents

A fejlesztéshez használható · Budapesti 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 Tanszék