Rendszertervezés (Embedded System Design) VIMIM238 BME MIT: MSc beágyazott információs rendszerek szakirány

Átírás

1 Rendszertervezés (Embedded System Design) VIMIM238 BME MIT: MSc beágyzott információs rendszerek szkirány Órvázlt 2010 Csk belsı hsználtr Scherer Blázs Lektorált: Csordás Péter Jvítási jánlások v2.3-hoz: Szegı Márton

2 Rendszertervezés (VIMM238) 2 1. BEVEZETÉS MIÉRT VAN SZÜKSÉGÜNK VALAMILYEN RENDSZERFEJLESZTÉSI MÓDSZERTANRA? MINİSÉGI SZABVÁNYOK CAPABILITY MATURITY MODEL INTEGRATION (CMMI) Bevezetés, CMMI filozófiáj A lépcsızetes megközelítés érettségi szintjei folytonos megközelítés képességi szintjei A CMMI folymti és kpcsolt lépcsıs és folytonos megközelítés között A CMMI folymtink rövid ismertetése Egy beágyzott project fejlesztése során z egyes feldtokr fordított idı A FEJLESZTÉST TÁMOGATÓ ÉS MENEDZSMENT FOLYAMATOK PROJECT PLANNING A Gntt digrmm Constructive Cost Model REQUIREMENT MANAGEMENT (KÖVETELMÉNY MENEDZSMENT) CONFIGURATION MANAGEMENT (KONFIGURÁCIÓMENEDZSMENT) A konfigurációmenedzsmentben célj A konfigurációmenedzsment folymt lépései A konfigurációmenedzsment és verziókövetés viszony A RENDSZERTERVEZÉS FEJLESZTÉSI FOLYAMATAI A FEJLESZTÉSI FOLYAMATOK ÉLETCIKLUS MODELLJEI A Vízesés modell A Spirál modell A V-modell A V-MODELL TERVEZÉSI LÉPÉSEI Követelménynlízis, és Logiki rendszerterv elkészítése A logiki rendszer rchitektúr elemzése, techniki rendszer rchitektúr specifikációj Szoftver követelmények elemzése és szoftver rchitektúr megtervezése Szoftver komponensek specifikálás A szoftver komponensek implementálás A megfelelı implementációs környezet kiválsztás A V-MODELL TESZTELÉSI ÁGA Szoftverkomponensek tesztelése Szoftverkomponensek integrációj A szoftverrendszer tesztelése Rendszerintegráció és integráció tesztelése Végfelhsználói teszt GYAKORLATI ANYAGOK VERZIÓKÖVETÉS SVN-EL DOKUMENTÁCIÓGENERÁLÁS KOMMENTBİL DOXYGEN-EL C KÓDOLÁSI SZABÁLYOK: MISRA-C, CERT SECURE C MISRA-C szbályok IRODALOMJEGYZÉK Scherer Blázs (scherer@mit.bme.hu), 2010.

3 Rendszertervezés (VIMM238) 3 1. Bevezetés 1.1. Miért vn szükségünk vlmilyen rendszerfejlesztési módszertnr? Egy módszertn segítségével fejlesztett rendszer, vgy szoftver fejlesztési költsége viszonylg mgs kezdı értékrıl indul, de fejlesztési munk és bonyolultság elırehldásávl csk közel lineárisn nı, míg egy módszertn nélkül létrehozott rendszer vgy szoftver költsége bár 0-ról indul, de bonyolultság növekedésével exponenciálisn nı, ezzel szinte grntálv, hogy egy ngyobb projekt kifut z idıbıl, és túllépi költségkeretet. Érdemes megnézni Stndish Group áltl szoftver projectekkel kpcsoltbn végzett felmérés eredményét 1.1 ábr (Nem csk beágyzott projekteket trtlmz felmérés). A Successful z idıben befejezett sikeres projekteket jelenti. A Chllenged zokt, mik vlmilyen nehézséggel küzdöttek (pl. költség keret- vgy idıtúllépés) de végül sikeresen zárultk, Filed pedig fejlesztés közben bbhgyott projecteket jelzi. Stndish Group CHAOS Report Successful Chllenged Filed % 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Successful 16% 27% 26% 28% 34% 29% 35% 32% Chllenged 53% 33% 46% 49% 51% 53% 46% 44% Filed 31% 40% 28% 23% 15% 18% 19% 24% 1.1 ábr. A Stndish Group [1] felmérése szoftver projektek eredményességérıl Jól láthtó, hogy z 1994-es évhez képest 2000-es években már érzékelhetı jvuláson ment keresztül szoftverfejlesztıi pic. Érdemes megjegyezni, hogy cégeknél különbözı rendszerfejlesztési modellek elsısorbn z 1990-es évek második felétıl kezdtek elterjedni. Például z ISO9001 minıségbiztosítási szbvány 1996-bn dták ki, z áltlunk sokt hivtkozott V-modell elsı verziój pedig 1997-ben került publikálásr. Ezekre z évekre tehetı képesség-érettség modellek (CMM: Cpbility Mturity Modell) lklmzásánk bevezetése is. Igz ez nnk ellenére, hogy rendszerfejlesztési életciklus egyik meghtározó modelljét vízesés modell-t már 1970-ben publikálták. Észrevehetı ugynkkor, hogy 2000-es évekre csk stgnálás jellemzı, gykorltilg nincs elırelépés. Mi indokolj zt, hogy z elméletileg fokoztosn fejlıdı projekt végrehjtási módszertnok és pprátus mellett sem nıtt z eredményes projektek rány? A válsz Scherer Blázs (scherer@mit.bme.hu), 2010.

4 Rendszertervezés (VIMM238) 4 megértéséhez elég, h megnézzük beágyzott rendszerek fejlıdési ütemét z elmúlt pár évben 1.2 ábr. (hsonló tendenci igz z sztli számítógépes szoftver projecteknél is). 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0, Progrm memóri Adt memóri Rendszer órjel Ár 1.2 ábr. A beágyzott vezérlık jellemzıinek változás z 1990-es évektıl npjinkig (z y tengely mindig legmgsbb értékhez vett rányokt muttj) A számszerő dtokt érzékelteti z 1. táblázt, mi bemuttj egy tipikus utóipri ECU-bn (Electronic Control Unit) lklmzott feldolgozó egység változásit ( bemuttott táblázt nem egy vezérlıtípus részletes eredménye, hnem több ilyen táblázt összefogllás). [1] [2] 1. táblázt. Egy tipikus erıátviteli rendszerben lklmzott utóipri ECU feldolgozó egységének változás z elmúlt 20 évben Adtszélesség Progrm Adt memóri Órjel memóri bit 8 kbyte 128 byte 4 MHz bit 64 kbyte 256 byte 8 MHz bit 256 kbyte 2 kbyte 20 MHz bit 512 kbyte 16 kbyte 40 MHz bit 2+ Mbyte 64+ kbyte 100+ MHz Az 1.2 ábr és z 1. táblázt segítségével tehát könnyen levonhtjuk zt következtetést, hogy z elmúlt évtizedben bár csk szinten mrdt sikeres projektek rány, de ezt nnk ellenére sikerült elérni, hogy projectek komplexitás és mérete közben minimum megnégyszerezıdött. Ez így már nem rossz teljesítmény. El lehet képzelni, hogy mennyi lenne sikeres projectek rány ezen körülmények között, h z 1994-es mérésnél hsznált módszereket és tool-okt lklmznák mnpság is. De miben is tud segíteni egy rendszertervezési módszertn, és egy rendszer tudtos tervezése? H megnézzük 1.3 ábrát, kkor információt kphtunk rról, hogy egy project során átlgosn hol vétünk hibákt, hol fedezzük fel ıket és mennyi energiáb, illetve nygi ráfordításb kerül zok kijvítás. Az 1.4 ábrán hibjvítás költségét láthtjuk számszerősítve. Scherer Blázs (scherer@mit.bme.hu), 2010.

5 Rendszertervezés (VIMM238) ábr. Egy projekt során elkövetett hibák eloszlás, hibák megtlálás, és jvítás költsége [4]. 1.4 ábr. A hibjvítás költségének rányi egy másik forrásból [4] Az 1.3 ábrából láthtó, hogy legtöbb hib tervezés végsı szkszábn és progrmozás során kerül rendszerbe, ezért legtöbb fejlesztési módszertn úgy épül fel, hogy ezek lépések már ngyon pontosn specifikáltk legyenek. Mnpság legtöbb esetben igyekeznek ezeket z utolsó lépéseket utomtizálni. A tesztelés során jól specifikált fejlesztési módszertnok bbn tudnk segítséget nyújtni, hogy szisztemtikus tervezés következtében már komponens szinten tehát z ábránál Unit-test/Module-test folymtrészen igyekeznek legtöbb hibát megtlálni. Ezáltl z ábr detected error görbéjét mindinkább blr tolv csökkenthetı hibjvítás költsége. Egy nem megfelelı rchitektúrábn írt szoftver kori fázisbn végzett szisztemtikus tesztelése például mjdnem lehetetlen bonyolultság és z egymásr htások mitt (nem teljesül áltlábn jól szeprált komponensekre bontás és zok külön tesztelése). Az így rendszerben benne mrdó lppngó hibák csk késıbb jönnek ki, ezzel jóvl ngyobb nygi és emberi erıforrás kárt okozv. Scherer Blázs (scherer@mit.bme.hu), 2010.

6 Rendszertervezés (VIMM238) 6 A fejlesztési modellek hsználtánk másik nyomós indok, hogy mi világbn ngyon sok termék több cég kooperációjábn készül el. Ezekben z esetekben egyrészt z egyes cégek elvárják prtnertıl, hogy igzolni tudják, zt hogy sját project részük idıre és megfelelı minıségben fog elıállni. Másrészt fejlesztés közben is sok esetben szükség vn együttmőködésre, és ezt kooperációt ngybn megkönnyíti z zonos fejlesztési módszerek és metódusok hsznált Minıségi szbványok Az elızı fejezet rávilágított rr, hogy miért lehet fontos egy fejlesztési módszertnt hsználni rendszereink tervezésénél. Ugynkkor felmerülhet bennünk z kérdés, hogy miért fejlesztési folymtokkl fogllkozunk és miért nem mgávl késztermékkel, minek minıségét grntálni krjuk. Erre z válsz, hogy bár voltk és vnnk rá kísérletek (például z ISO-9126 szbvány), de például egy szoftvernél, mint készterméknél igen nehézkes megállpítni minıségét. Fokozottn igz ez egy beágyzott szoftverre. Ezért egyszerőbb és htékonybb, h termék legyen szó hrdverrıl vgy szoftverrıl fejlesztésének mikéntjét vizsgáljuk. Nézzük meg, hogy mgávl fejlesztési folymt minısítésével milyen nemzetközi szbványok fogllkoznk. A fejlesztési minıségbiztosításbn leggykrbbn z ISO9001:2000, CMMI és z ISO/IEC vgy más néven SPICE szbvánnyl lehet tlálkozni. Az ISO9001:2000 szbvány egy áltlánosbb bármilyen folymtr lklmzhtó minıségbiztosítási módszer, mely termékfejlesztés folymtánk kilkításához, egy minıségügyi rendszer létrehozásához, z erıforrások, és vevı megfelelı kezeléséhez nyújt keretet. Az ISO 9001-et áltlánosság mitt (kár egy ropis zcskón is tlálhtunk ISO9001-es hivtkozást) kifejezetten nehéz értelmezni szoftver és hrdver fejlesztési folymtokr. Ahhoz, hogy egy ilyen lklmzás egy cégnél elkészüljön igen tpsztlt rendszerfejlesztık kellenek. Megjelent ugynkkor egy kiegészítés ISO90003:2000 néven, mely kifejezetten szoftverlklmzásokhoz nyújt útmuttást. Ez kiegészítés sokt merít CMMI-ból és z ISO-9126-ból. A Cpbility Mturity Model Integrtion (CMMI) és SPICE (Softwre Process Improvement nd Cpbility determintion) szőkebb, speciálisn z informtiki/szoftver rendszerek fejlesztésére kidolgozott szbványok, melyek elsısorbn z ilyen tevékenységgel fogllkozó vállltoknál lettek egyre népszerőbbek z elmúlt években. A legtöbb informtiki vgy szoftver tevékenységgel rendelkezı válllt z ISO9001-es minısítés mellett CMMI vgy SPICE minısítéssel is rendelkezik. A két szbvány távolról nézve erıs hsonlóságokt trtlmz ( kettı célj is közel zonos). A SPICE CMMI lpját dó CMM képességi-érettségi modellekkel együtt 90-es évek közepén-végén jelent meg, és elsısorbn z egyes rendszertervezési folymtok képességi szintjeinek elemzésével fogllkozik. A késıbb megjelenı CMMI for Development egy integrálás 90-es években megjelent képességi-érettségi modelleknek (CMM), és sok foglmt átvesz SPICE-ból is Cpbility Mturity Model Integrtion (CMMI) Bevezetés, CMMI filozófiáj Scherer Blázs (scherer@mit.bme.hu), 2010.

7 Rendszertervezés (VIMM238) 7 Az 1.3-s fejezetben CMMI for Development [5],[6] minket érintı részeinek rövid összefogllás következik. Egy cégnél fejlesztés minısége z bbn résztvevı emberek képzettségén, z lklmzott eljárásokon és módszereken, vlmint z ezek végrehjtásához hsznált eszközökön múlik. Ezeket komponenseket cégnél lklmzott fejlesztési folymt (Process) fogj össze. Procedures nd methods defining the reltionship of tsks B A C D PROCESS People with skills, trining, nd motivtion Tools nd equipment 1.5 ábr. Egy project sikerességét befolyásoló tényezık A CMMI célj, hogy cégeknél lklmzott folymtok fejlesztésére és minısítésére djon szbványt, több régebbi Cpbility Mturity Model-t integrálv. A CMMI lpvetıen kétfjt megközelítést kínál folymtok fejlesztésére folytonost (Continous Representtion) és lépcsıst (Stged Representtion) (mindkettınek ugynz z eredménye csk z út más). A folytonos megközelítés ngy szbdságfokot enged fejleszteni kívánt CMMI folymtok meghtározásánál. Ez megközelítés elsısorbn zoknk jánlott, kik tisztábn vnnk fejlesztési folymtokkl és tudják, hogy min szeretnének jvítni. Tehát folytonos megközelítésében mg modell lklmzój dönti el, hogy melyik folymtot kívánj vizsgálni. A folymt kiválsztás után lehetısége vn z dott folymt képességi fokoztát megállpítni, és útmuttást kp rr vontkozón, hogy mit kell hhoz tenni, hogy következı képességi szintre jusson z (A SPICE hsználj még ezt folytonos megközelítést). A kezdıknek elsısorbn lépcsızetes megközelítés jánlott, hol több évtizedes tpsztltokból kiindulv konkrét lépcsıkre vn bontv folymtok fejlesztése. Ebben z esetben nem külön z egyes folymtokt vizsgálj modell, hnem egyben z egész fejlesztési folymtot, és zt dj meg, hogy z dott érettségi szintek, eléréséhez milyen folymtokt kell implementálni (A régebbi CMM-ekre volt ez jellemzı). Tehát összefogllv folytonos megközelítés z egyes folymtokt és zok képességeit vizsgálj és fejleszti külön-külön. A lépcsızetes megközelítés pedig z egész szervezet érettségét vizsgálj és fejleszti. Természetesen két megközelítés erıs kölcsönhtásbn vn egymássl, és léteznek megfelelıségek közöttük. Ezekrıl késıbbiekben lesz szó A lépcsızetes megközelítés érettségi szintjei A CMMI lépcsızetes megközelítése z egész szervezetre vontkozón 5 érettségi szintet specifikál. Scherer Blázs (scherer@mit.bme.hu), 2010.

8 Rendszertervezés (VIMM238) 8 1. szint: Initil (kezdeti) 2. szint: Mnged (menedzselt/irányított) 3. szint: Defined (meghtározott) 4. szint: Quntittively Mnged (mennyiségileg menedzselt/irányított) 5. szint: Optimizing (optimlizáló) Ezek jelentése következı: 1. Initil (kezdeti) A folymtok d-hoc jellegőek, és kotikusk. A szervezet nem képes stbil környezet létrehozásár project számár. Az eredményesség elsısorbn dolgozók tudásán és hısiességén múlik. Bár z ezen z érettségi szinten álló szervezetek is áltlábn mőködı dolgokt hoznk létre, de z esetek többségében túllépik z idıkeretet, vgy z elıre klkulált költséget. Válsághelyzetben (gykorltilg mindig z vn) folymtokt figyelmen kívül hgyják és képtelenek sikerek megismétlésére. 2. Mnged (menedzselt/irányított) A szervezet biztosítj, hogy projectjeiben folymtokt tervezik, ellenırzik, mérik és végrehjtják. A menedzsment számár project állás és termék állpot z elıre meghtározott pontokon világosn ellenırizhetı. A végtermék teljesíti kitőzött célokt és megfelel z elıre specifikált szbványoknk. 3. Defined (meghtározott) Ezen szinten szervezetnek elıre meghtározott szbványos folymti vnnk, melyeket folymtosn fejlesztenek. A projectekre ezeket szervezeti folymtokt szbják testre megfelelı útmuttó lpján. Az egyes processzek pontosbbn részletesebben leírtk, mint 2. érettségi szinten. Ehhez szinthez hozzátrtozik folymtos okttás és képzés is. 4. Quntittively Mnged (mennyiségileg menedzselt/irányított) A folymtok végrehjtásár és minıségére muttókt, mérıszámokt htároznk meg. Ezeket mérıszámokt győjtik z egyes projectek során, mjd elemzik zokt. A fı különbség 3. és 4. érettségi szint között, hogy 4. szinten folymtok teljesítménye jósolhtó z eddigi sttisztikákból, tehát számszerő, mennyiségi becslés áll rendelkezésre. 5. Optimizing (optimlizáló) A folymtokt rendszeresen jvítják, mérések lpján felmérik z ingdozások okit, és korrigálják zokt. A folymtok fejlesztési muttóit szervezeti szinten htározzák meg, és folymtosn hngolják z ktuális célokhoz. Érdemes megnézni, hogy egy 2006-os sttisztik szerint világon minısítést kpott vállltok hány százlék trtozik z egyes ktegóriákb (1.6. ábr). Scherer Blázs (scherer@mit.bme.hu), 2010.

9 Rendszertervezés (VIMM238) ábr. Az egyes érettségi szintek eloszlás egy 2006-os felmérés lpján. Érdemes megjegyezni, hogy szervezetek méretének növekedésével párhuzmosn nı z Optimlizáló szint elérésének rány is. Míg z fıt fogllkozttó szervezeteknél 10% körüli z Optimlizáló szint rány ddig z 1000 fı feletti szervezeteknél ez 40% fölött vn. Szintén z érettségi szintekhez trtozik, hogy távolról sem olyn könnyő ezeket elérni. Sttisztikák szerint z egyes érettségi szintek közötti fejlıdés minimum 1 évet, de sokszor 2 évet is igénybe vesz A folytonos megközelítés képességi szintjei A CMMI folytonos megközelítése z egyes folymtokr vontkozón 6 képességi szintet specifikál. Ezek következık: 0. szint: Incomplete (nem teljes, befejezetlen) 1. szint: Perfomed (végrehjtott) 2. szint: Mnged (menedzselt/irányított) 3. szint: Defined (meghtározott) 4. szint: Quntittively Mnged (mennyiségileg menedzselt/irányított) 5. szint: Optimizing (optimlizáló) 0. Incomplete (nem teljes, befejezetlen) A folymtot nem, vgy csk részben hjtják végre. 1. Perfomed (végrehjtott) A folymtot végrehjtják, teljesülnek folymt célji. 2. Mnged (menedzselt/irányított) A menedzselt folymtot elıre tervezik, végrehjtását megfelelı képességő emberek megfelelı erıforrásokkl végzik. A folymtot követik és ellenırzik. Egy ilyen szintő folymtnál biztosítv vn, hogy stressz ltt is végrehjtják. Scherer Blázs (scherer@mit.bme.hu), 2010.

10 Rendszertervezés (VIMM238) Defined (meghtározott) Ezen szinten z egyes folymtok végrehjtási módj szervezeti szinten meghtározott. Az egyes projecteknél testre szbják folymtot. A meghtározott folymtoknál sokkl kevesebb projectrıl projectre z eltérés, mint 2. szintő irányított folymtoknál, mert itt mindegyik egy közös szervezeti bázisból indul. A 3. szintő folymtok pontosbbn részletesebben is kerülnek meghtározásr. 4. Quntittively Mnged (mennyiségileg menedzselt/irányított) A folymt végrehjtásár mérıszámokt htároznk meg. Ezeket mérıszámokt győjtik z egyes projectek során, mjd elemzik zokt. A fı különbség 3. és 4. érettségi szint között, hogy 4. szinten folymt teljesítménye jósolhtó, z eddigi sttisztikákból. 5. Optimizing (optimlizáló) A folymtokt folymtosn jvítják. A mérések lpján felmérik z ingdozások okit, és korrigálják zokt. A folymtok fejlesztési muttóit szervezeti szinten htározzák meg, és folymtosn hngolják z ktuális célokhoz A CMMI folymti és kpcsolt lépcsıs és folytonos megközelítés között Az elızı két lfejezetben rról beszéltünk, hogy hogyn értelmezzük egy szervezet érettségét, és szervezet folymtink képességét, de nem említettük meg, hogy CMMI szerinti szemléletben egy rendszertervezési projekt milyen folymtokból áll. Ez fejezet ismerteti CMMI áltl definiált folymtokt, és bemuttj, hogy z egyes érettségi szintekhez milyen folymtok lklmzás kötelezı. A CMMI for Development 22 folymtot zonosít, ezek következı ngy csoportokb oszthtók: Engineering (mérnöki, fejlesztési) Project mngement (projektmenedzsment) Process mngement (folymt menedzsment) Support ( fejlesztést támogtó folymtok) Ezeket z 1.7 ábr próbálj meg csoportosítni és logikilg összekpcsolni (Az ábr nem minden esetre teljesen helytálló). A folymtcsoportok között próbáljuk jelezni z egymáshoz rendeltség viszonyát, vstg nyíl szbályozást és megkötéseket, vékonybb nyíl dtszolgálttást és visszcstolást jelent. Scherer Blázs (scherer@mit.bme.hu), 2010.

11 Rendszertervezés (VIMM238) 11 Folymt menedzsment Projekt menedzsment folymtok Fejlesztési / Mérnöki folymtok Fejlesztést támogtó folymtok Projekt 1 Projekt 2 Projekt n 1.7 ábr. A rendszertervezés CMMI szerinti folymt osztályi A folymt csoportok bemuttás után következzen z egyes folymtok felsorolás, mjd értelmezése. A folymtok felsorolásár hsznált 2. táblázt egyben trtlmzz zt is, hogy z egyes CMMI-bn definiált érettségi szintekhez szervezeteknek milyen folymtokt kell implementálniuk, illetve ezeket milyen képességi szinten kell megvlósítni. A tárgy során természetesen nem ismertetjük z összes folymtot részletesen, hnem elsısorbn csk mérnöki fejlesztési folymtokr koncentrálunk, kiegészítve zokt néhány mérnöki életben megkerülhetetlen támogtó folymttl. Scherer Blázs (scherer@mit.bme.hu), 2010.

12 Rendszertervezés (VIMM238) 12 A folymt neve A folymt típus Érettségi szint Mturity Level Requirements Mngement (Követelménymenedzsment) Mérnöki / fejlesztési 2 Project Plnning (Projecttervezés) Projekt menedzsment 2 Project Monitoring nd Control (Projectkövetés és vezérlés) Projekt menedzsment 2 Supplier Agreement Mngement (Beszállítói megállpodás menedzsment) Projekt menedzsment 2 Mesurement nd Anlysis (Mérés és Anlízis) Fejlesztést támogtó 2 Process nd Product Qulity Assurnce (Folymt és termék minıség biztosítás) Fejlesztést támogtó 2 Configurtion Mngement (Konfigurációmenedzsment) Fejlesztést támogtó 2 Requirements Development (Követelményfejlesztés) Mérnöki / fejlesztési 3 Technicl Solution (Mőszki megoldás) Mérnöki / fejlesztési 3 Product Integrtion (Termék Integráció) Mérnöki / fejlesztési 3 Verifiction (Verifikáció) Mérnöki / fejlesztési 3 Vlidtion (Vlidáció) Mérnöki / fejlesztési 3 Orgniztionl Process Focus (Szervezeti szintő folymtszemlélet) Folymt menedzsment 3 Orgniztionl Process Definition +IPPD* (Szervezeti folymtok meghtározás) Folymt menedzsment 3 Orgniztionl Trining (Szervezeti szintő képzés) Folymt menedzsment 3 Integrted Project Mngement +IPPD* (Integrált projektmenedzsment) Projekt menedzsment 3 Risk Mngement (Kockáztmenedzsment) Projekt menedzsment 3 Decision Anlysis nd Resolution (Döntés elemzés és döntés hoztl) Fejlesztést támogtó 3 Orgniztionl Process Performnce (Szervezeti szintő folymtmenedzsment) Folymt menedzsment 4 Quntittive Project Mngement (Mennyiségi projektmenedzsment) Folymt menedzsment 4 Orgniztionl Innovtion nd Deployment (Szervezeti szintő innováció és közzététel) Folymt menedzsment 5 CL1 CL2 CL3 CL4 CL5 Érettségi szint 2 Érettségi szint 3 Érettségi szint 4 Cusl Anlysis nd Resolution (Oksági elemzés és megoldás) Fejlesztést támogtó 5 Érettségi szint 5 *IPPD: Integrált folymt és termék menedzsment 2. táblázt. A CMMI folymti és z érettségi szintek kpcsolt Scherer Blázs (scherer@mit.bme.hu), 2010.

13 Rendszertervezés (VIMM238) A CMMI folymtink rövid ismertetése Aláhúzv késıbbiekben picit részletesebben ismertetett folymtok. Requirements Mngement (Követelmény menedzsment) ML2 Célj project áltl elıállított termékre vontkozó követelmények elemzése és nyilvántrtás z inkonzisztenciák kiszőrésére. A nem megvlósíthtó követelményeket fel kell fedni, és megrendelıvel egyeztetni kell további sorsukról. A folymt végzi el követelménykövetést, z ún. requirement trcking-et. Project Plnning (Projecttervezés) ML2 Célj projekt tevékenységeinek meghtározás és z ezek végrehjtásához szükséges tervek létrehozás. A tervezés mgáb fogllj munktermékek és feldtok megbecsülését, szükséges idı és erıforrások meghtározását, kötelezettségek egyeztetését, z ütemterv megállpítását, vlmint project kockáztink zonosítását és elemzését. Project Monitoring nd Control (Projectkövetés és vezérlés) ML2 A projectfolymtok végzésének ellenırzése, eltérés esetén korrekció, hibjvítás. Feldti többek között költség és z ütemterv összevetése tervekben szereplıkkel meghtározott mérföldköveknél. Jvításr áltlábn csk jelentıs eltérés esetén vn szükség. Supplier Agreement Mngement (Beszállítói megállpodás menedzsment) ML2 Áltlábn csk zokbn z esetekben szükséges, h vlmilyen hrdwre komponens is átdásr kerül, de lklmzhtják fejlesztésnél hsznált termékek beszerzésére is. A folymt célj termék típusok és beszállítók kiválsztás, megállpodás beszállítókkl vlmint beszerzett lktrészek ellenırzése és beleintegrálás termékbe. Mesurement nd Anlysis (Mérés és Anlízis) ML2 Ezek mérések elsısorbn menedzsment információs igényeinek kiszolgálásár szolgálnk. Segítik folymtok tárgyilgos becslését és teljesítmény követését. Céljuk mérendı mennyiségek zonosítás, és metrik meghtározás. Szükséges továbbá z dtok tárolási módjánk meghtározás is. Process nd Product Qulity Assurnce (Folymt és termék minıség biztosítás) ML2 Cél z objektív betekintés biztosítás folymtokb és munktermékekbe. Ezek áltl lehetıség vn z egyes végrehjtott folymtokt, termékeket és szolgálttásokt értékelni. Tipikusn vlmilyen projekttıl független minıségbiztosítási csoport végzi szervezeten belül. Configurtion Mngement (Konfigurációmenedzsment) ML2 A termék különféle verzióink z elıállításáért felelıs, közük z lpverzióért és z bból szármzttott speciális verziókéért. Nyilván kell trtni z egyes komponensek közül zokt csoportokt, melyek együtt mőködıképesek, beleértve hozzájuk trtozó követelményeket és követelménykövetési dokumentációt. Szükség esetén biztosítni kell, hogy minden idıpillntbn legyen egy mőködı konfiguráció. Requirements Development (Követelmény fejlesztés) ML3 Termék és termékkomponens követelményeinek létrehozás. Célj z ügyféllel együttmőködve követelmények összegyőjtése, elemzése, jóváhgyás. A követelmények nem csk mgár termékre vontkozhtnk, hnem nnk elıállítási módjár, z lklmzott Scherer Blázs (scherer@mit.bme.hu), 2010.

14 Rendszertervezés (VIMM238) 14 metódusokr is. A folymt egyik fı célj, hogy ezt követelmény -győjtést, -elemzést és z ügyfélnek vló megfelelést fokoztosn finomíts, fejlessze. Technicl Solution (Mőszki megoldás) ML3 Célj termék megvlósítás. A lehetséges megoldások kiválsztás, kiválsztás után tervkészítés, mjd nnk megvlósítás. Product Integrtion (Termék Integráció) ML3 Az egyes termékek összeállítás rendszerré, rendszer mőködésének ellenırzése. Verifiction (Verifikáció) ML3 Annk ellenırzése, hogy helyesen terveztünk-e. Vlidtion (Vlidáció) ML3 Annk ellenırzése, hogy jót terveztünk-e. Orgniztionl Process Focus (Szervezeti szintő folymtszemlélet) ML3 Célj szervezet folymtink feltérképezése és szervezeti szintő fejlesztése. A folymtok mgukb fogllják szervezet szbványos folymtit, és z ezekbıl testre szbott konkrét projectekre jellemzı folymtokt is. A folymtok jvítás figyelembe veszi mérések eredményeit. Ezért tevékenységért tipikusn egy külön csoport felel, kik fejlesztésbe bevonják z dott folymtok végrehjtóit is, és elkészítik folymtfejlesztési terveket. Orgniztionl Process Definition (Szervezeti folymtok meghtározás) ML3 A szervezeti folymttpsztltok összegyőjtése, széles körben hsználhtó részek közzététele és krbntrtás célj. Segítséget nyújt folymtfejlesztéshez. Gykorltilg z így elıálló dtbázis trtlmzz z összes tpsztltot rról, hogy szervezetnél milyen módszerek szerint lklmzzák, készítik el z egyes folymtokt. Útmuttót d rr vontkozv is, hogy ezeket z áltlános tpsztltokt hogyn szbják testre z egyes projekteknél. Orgniztionl Trining (Szervezeti szintő képzés) ML3 Célj dolgozók szkértelmének és tudásánk fejlesztése. Felméri z igényeket, megszervezi tréningeket, begyőjti visszjelzéseket. Integrted Project Mngement (Integrált project menedzsment) ML3 Célj z egyes projectek létrehozás, és projectben közremőködık kiválsztás. Meghtározz project folymtit szervezeti dtbázis lpján. Meghtározz project költség és idıkeretét, vlmint ütemtervét. Risk Mngement (Kockáztmenedzsment) ML3 Célj potenciális problémák zonosítás, mielıtt zok gondot okoznánk. Az egyes kockáztok zonosítás után zokr kezelési strtégiát kell meghtározni, zt be kell vonni termék életciklusáb. A külsı és belsı kockáztokt és zok htását z ütemtervre és költségre is mérlegelni kell. Decision Anlysis nd Resolution (Döntéselemzés és döntés hoztl) ML3 Célj z egyes döntési helyzetekhez formális módszer nyújtás. Létrehozz z áltlános döntési kritériumokt kiértékeléshez. A folymt feldti közé trtozik z lterntív megoldások zonosítás, vlmint z egyes lterntívák kiértékelése. Alklmzás elsısorbn Scherer Blázs (scherer@mit.bme.hu), 2010.

15 Rendszertervezés (VIMM238) 15 mőszki döntéseknél jellemzı. Ilyen döntések beszállítók, z újr felhsználhtó modulok, fejlesztıkörnyezetek kiválsztás. Orgniztionl Process Performnce (Szervezeti szintő folymtteljesítmény) ML4 Az egyes folymtokhoz trtozó teljesítményjellemzık meghtározás, győjtése, sttisztiki értékelése. Az egyes projectekre becslés dás meglévı szervezeti sttisztikából. Quntittive Project Mngement (Mennyiségi project menedzsment) ML4 A project mennyiségi céljink meghtározás. A project egyes szkszihoz mérıszámok rendelése, vlóság és tervezett mérıszámok lkulásánk követése. A sttisztikák begyőjtése és elemzése, z eltérések okink vizsgált. Orgniztionl Innovtion nd Deployment (Szervezeti szintő innováció és közzététel) ML5 Összegyőjti továbbfejlesztési jvsltokt és elemzi zokt. A hsznos jvsltok kiszőrése és prototípus bevezetése. A sikeres prototípus után változttások közzététele, és továbbfejlesztés menedzselése. Cusl Anlysis nd Resolution (Oksági elemzés és megoldás) ML5 A hibdtok begyőjtése és elemzése, z okok feltárás. Annk ellenırzése, hogy z dott hib csk z dott projectre jellemzı, vgy áltlános problém. A feltárt okok megszüntetése A CMMI modell uditálás SCAMPI A SCAMPI (Stndrd CMMI Apprisl Method for Process Improvement) felméréseknek három típusát különböztetjük meg: A, B, C. Az A típusú, formális SCAMPI felméréseket hivtlos, SEI áltl elfogdott vezetı uditorok végezhetik. Ez legformálisbb módszer és csk e módszer lpján szbd érettségi vgy képességi szintet megállpítni. A B típusú felmérést leginkább z A-t megelızıen szoták lklmzni elızetes femérésként. Ekkor zt mérik fel, hogy mire vn még szükség hhoz, hogy egy SCAMPI A típusú felmérésen is minden követelménynek megfeleljen szervezet. A C típusú felmérések bevezetı jellegőek, melyek során zt mérik fel, hogy mi lehet egy reális cél z dott szervezet számár, mely folymtit fejlessze. Rendszerint egy C típusú (gp-nlysis)-el indul folymtfejlesztés Egy beágyzott project fejlesztése során z egyes feldtokr fordított idı A fejezetben bemuttott folymtok szám és leírás után z z érzésünk támdht, hogy z eddigi tnulmányok során elsjátított részek igencsk kis hánydát teszik ki felsoroltknk. A kérdés z, hogy vlóságbn egy project végrehjtásánál melyik folymt mekkor súllyl szerepel. Erre legjobb válszt tlán z Embedded Mrket Study 2009-ben [] készített sttisztikáj nyújtj (1.8 ábr) Scherer Blázs (scherer@mit.bme.hu), 2010.

16 Rendszertervezés (VIMM238) ábr. A Embedded Mrket Study 2009 sttisztikáj z egyes project tevékenységek erıforrás igényérıl Ebbıl sttisztikából kitőnik, hogy tényleges progrmozás fejlesztés csk igen kis hánydát jelenti egy project elkészítésének, és bármilyen fájdlms is többi 99%-98% munkát is mérnökök végzik. (A sttisztikábn nem mérnöki feldtok nincsenek benne). Scherer Blázs (scherer@mit.bme.hu), 2010.

17 Rendszertervezés (VIMM238) A fejlesztést támogtó és menedzsment folymtok Ebben fejezetben röviden összefogllásr kerülnek z áltlunk hsználni kívánt fejlesztést támogtó és menedzsment folymtok Project menedzsment A project menedzsment egyik legfontosbb feldt, hogy project idıbeli lefutását megtervezze. Azonosíts z egyes végrehjtndó feldtokt, felmérje zok idıbeli és erıforrás költségét, llokálj z egyes feldtok végrehjtásához szükséges emberi és tárgyi erıforrásokt. Felmérje project futás ltt párhuzmosn végezhetı feldtokt, zonosíts z idıkritikus feldtsorokt, ágkt. A project tervezés során fontos olyn mérföldkövek megállpítás, mely pontokon project állás, hldás felmérhetı. Ilyen mérföldköveknél belsı, vgy külsı ellenırzéseket (udit) szoktk trtni. A project tervezés fogllkozik még project céljánk és termékeinek kijelölésével is, vlmint project kockáztink zonosításávl is. A tervezés legfontosbb lépései összefogllv: Becslések végzése o Végtermékek és feldtok becslése o A project életciklusánk meghtározás o Ráfordítás és költség becslése Projectterv kilkítás o Költségek és ütemterv meghtározás o Kockáztok zonosítás o Erıforrások tervezése o Szükséges tudás és szkképzetség meghtározás. o Adtmenedzsment megtervezése o Projectterv dokumentálás Projectkövetés terv lpján o Projecttervezési prméterek követése o Kockáztok követése o Adtmenedzsment követése o Mérföldkı ellenırzések. Jvítás o Problémák elemzése o Jvító intézkedések megtétele és menedzselése A projekt idıtervének elkészítésére legtöbb helyen vlmilyen CAD progrmot hsználnk, ilyen például Microsoft Project, vlmint egy ingyenesen letölthetı projekttervezı progrm z Openproj [2.1]. Ezek projekttervezık tipikusn feldtok és zok idıigényének, költségének bevitelét támogtják. Ezekbıl z dtokból tudnk vlmilyen szemléletes, átfogó megjelenítést létrehozni A Gntt digrmm A feldtok egymásutániságánk és egymásr épüléseinek megjelenítésére legtöbbet hsznált eszköz tlán z ún. Gntt digrmm, melyet legtöbb CAD rendszer támogt. A másik igen elterjedt megjelenítés Pert chrt. Áltlábn egymás mellett léteznek ezek megjelenítési módok. Scherer Blázs (scherer@mit.bme.hu), 2010.

18 Rendszertervezés (VIMM238) 18 A Gntt digrmmot között fejlesztette ki Henry L. Gntt [2.2]. A sorokbn z egyes feldtokt tláljuk, z oszlopokbn pedig hónpokt. Egy feldt végrehjtási idejét egy-egy vízszintes vonl jelöli, míg z egyes folymtok egymásr htását nyilk jelzik. Egy Gntt digrmm létrehozásához következı dtokt kell megdni: Folymt neve A folymt idıigénye A folymt legkorábbi lehetséges kezdési idıpontj A folymt függése más folymtoktól A 2.1 ábrán egy tipikus projekt folymtit és nnk idıbeli lefolyását látjuk Gntt digrmmon ábrázolv. Scherer Blázs (scherer@mit.bme.hu), 2010.

19 Rendszertervezés (VIMM238) 19 Itertion 1 Softwre development Hrdwre development Integrtion 2.1 ábr. Egy projekt folymti és Gntt digrmmj First genertion pilot product Itertion 2 Finl product Scherer Blázs (scherer@mit.bme.hu), 2010.

20 Rendszertervezés (VIMM238) Constructive Cost Model A projekttervezés lpvetı problémáj szükséges erıforrások és idı megbecsülése. Erre becslésre többfjt lehetıség vn: Anlógi más fejlesztési projektekkel Szkértıi vélemény Cost modell lpú becslések Szinte z összes mgs CMMI minısítéssel rendelkezı cégnek (Mturity Level 4 és felette) részletes sttisztiki nyilvántrtás vn z eddig elkészült fejlesztéseirıl és zok idıigényérıl. Azokbn z esetekben, hol ilyen elızetes dt nem áll rendelkezésre sokszor Cost modell lpú becsléseket dnk. Egy ilyen Cost modell lpú becslésre egy klsszikus péld z 1981-ben Brry Boehm áltl publikált COCOMO (Constructive Cost Model) [2.3]. Hogy értsük ezeknek modelleknek mőködését, nézzük meg z egyszerősített COCOMO modell mőködését: Definíciók: Eff: Effort Applied (Szükséges erıforrás) KLOC: Kilo Line of Code (1000 kódsor) Dt: Development Time (Fejlesztési idı) P: People required (Szükséges fejlesztık szám) Eff ) b ( KLOC [mn months (ember hónp)] Dt ) P Eff / Dt [people (ember)] d c( Eff [months (hónp)] Az, b, c, d konstnsok project típus függıek. Softwre project b c d Normál 2,4 1,05 2,5 0,38 Embedded 3,6 1,2 2,5 0,32 3. táblázt COCOMO konstnsok Mintpéld: Péld 10,000 sor esetében (ngyjából helytálló egy jtó vezérlıre). Beágyzott Eff 3.6(10) [ember hónp] 0.32 Dt 2.5 (57) 9[hónp] P 57 / [ember] Nem beágyzott esetre Eff 2.4(10) [ember hónp] 0.38 Dt 2.5 (27) 9 [hónp] P 27 / 9 3[ember] Scherer Blázs (scherer@mit.bme.hu), 2010.

21 Rendszertervezés (VIMM238) 21 A fenti számokból érzıdik, hogy COCOMO egy ngyon elngyolt becslést d (beágyzott rendszerek esetében egyébként ngyságrendileg ilyen számokkl számolnk fejlesztı cégek is). A modellnek léteznek már sokkl finombb verziói is, például COCOMO2, hol rengeteg plusz információt figyelembe vesznek. Ilyen például z újr felhsznált illetve külsı helyrıl szármzó kódsorok szám, e kódok integrálási nehézségei. Gykorlti tnácsként egy projekt idıtervezéshez érdemes ismerni C. Northcote Prkinson törvényét, mely szerint: Egy munk mindig nnyir terjed ki, hogy kitöltse z elvégzésére felhsználhtó idıt. Ezt z ember mgán is gykrn tpsztlj, hát még másokon (Érdemes elolvsni Prkinson más megállpításit, h meg krjuk ismerni ngy szervezetek mőködésének emberi tényezıit) Requirement Mngement (Követelmény menedzsment) A követelmény menedzsment folymt célj projekt áltl elıállított termékre vontkozó követelmények elemzése, nyilvántrtás és zok inkonzisztenciáink kiszőrésére. A nem megvlósíthtó követelményeket fel kell fedni, és megrendelıvel egyeztetni kell további sorsukról. A követelmények megdásánk és győjtésének formlizálásár sokféle kísérlet történt már. Ezek közül tlán legutolsó SysML requirement digrmm-j. A gykorltbn zonbn legtöbb cégnél továbbr is egyszerő listként, például Excel tábláztokbn trtják számon követelményeket. Az egyes lrendszerek, modulok követelményeinek nyilvántrtás tervezés minden fázisábn fontos. (2.2 ábr). Felhsználói igények Logiki rendszer Techniki rendszerek Alrendszerek Követelmények A követelmény B követelmény C követelmény Megkötések X megkötés Y megkötés Z megkötés Az 1. funkció követelményei Követelmények A1 követelmény A2 követelmény C1 követelmény C2 követelmény C3 követelmény Megkötések X1 megkötés Y1 megkötés Y2 megkötés A3 megkötés Mechnik Követelmények Megkötések Elektronik Hrdwre Követelmények Megkötések Softwre rendszer Komponens 1 Követelmények Megkötések Komponens 2 Követelmények Megkötések Softwre Követelmények Megkötések Hrdwre rendszer 2.2 ábr. Követelmények és zok beépülése tervezésbe Mivel világunk nem ideális, ezért nyilvántrtásnál zt is figyelembe kell venni, hogy követelményeket projekt elején nem fog sikerülni 100%-os lefedettséggel elıállítni. Tehát sokszor szükség lehet rr, hogy fejlesztés közbeni követelményváltozásr regáljunk. Ezért fokozottn fontos, hogy nyomonkövessük, egyrészt felhsználói követelményrendszer változását, másrészt zt, hogy felhsználói követelmények közül melyik hov lett beépítve logiki és techniki rendszer rchitektúráb. Ez követelménykövetés, vgy z ún. requirement trcking, melynek célj, hogy követelmények és termék funkciói, tuljdonsági közötti kétirányú megfeleltetést biztosíts: egyrészt vissz kell tudni követni, Scherer Blázs (scherer@mit.bme.hu), 2010.

22 Rendszertervezés (VIMM238) 22 hogy mely rendszerjellemzık milyen követelmények mitt lettek kilkítv, illetve tudni kell zt is, hogy z egyes követelménypontok hogyn képzıdtek le funkciókká, megkötésekké. Felhsználói igények Logiki rendszer Techniki rendszerek Alrendszerek Követelmények A követelmény B követelmény C követelmény Megkötések X megkötés Y megkötés Z megkötés Az 1. funkció követelményei Követelmények A1 követelmény A2 követelmény C1 követelmény C2 követelmény C3 követelmény Megkötések X1 megkötés Y1 megkötés Y2 megkötés A3 megkötés Mechnik Követelmények Megkötések Elektronik Hrdwre Követelmények Megkötések Softwre rendszer Komponens 1 Követelmények Megkötések Komponens 2 Követelmények Megkötések Softwre Követelmények Megkötések Hrdwre rendszer 2.3 ábr Felhsználói igények és zok megvlósulásánk követése Bár requirement trcking egyszerő Excel munklpok segítségével is elvégezhetı, cégeknél sokszor olyn tool-okt hsználnk, melyek képesek követelmények közötti kpcsoltot, vlmint követelmények, megkötések beépülését termékbe követni. A tlán legelterjedtebb ilyen tool IBM Rtionl DOORS [2.4]. Egy beágyzott rendszeres projectben lpvetıen következı követelményeket szokták figyelembe venni (Példként megdjuk egy utó jtó vezérlésére vontkozó követelményeket): User Interfce requirements (követelmények felhsználói interfésszel szemben) Billenı kpcsoló, négyállású joy-stick stb. Funcionlity requirement (követelmények mőködéssel szemben) A gépkocsi minden jtónál sját vezérlés + vezetınél vezérelhetı legyen z összes jtó Open-Loop, close Loop requirements (szbályozási követelmények) Ablkemelınél kdás érzékelése és rekció. Rel time requirement (vlósidejüségi követelmények) Rekció 0,2 másodpercen belül Relibility requirements (megbízhtósági követelmények) Mőködjön minimum 10 évig C trtománybn. Sfety requirements (megbízhtósági követelmények) A kocsi induláskor központi zár záródjon be, H leszedik z kkumulátor srut, kkor újrinduláskor ne nyíljon ki központi zár. Instltion spce, weight, current drw requirements (elfogllt terület, súly, fogysztás követelmények) Sclbility nd vrint requirements (skálázhtóság, vriáns) Például egy egyszerőbb verzióbn ne lehessen vezetı oldláról mozgtni többiek blkát, ne legyen childlock funkció. Scherer Blázs (scherer@mit.bme.hu), 2010.

23 Rendszertervezés (VIMM238) 23 Qulity Requirements (minıség követelmények) Cost, effort, time to mrket requirements (költség, fejlesztési munk, picrkerülési idı követelményei) Amennyiben egy cég rendelkezik CMMI-bn specifikált require development folymttl, úgy z látj el requirement mngement folymtot inputtl Configurtion Mngement (Konfigurációmenedzsment) A konfigurációmenedzsmentben célj A konfiguráció menedzsment termék különféle verzióink z elıállításáért felelıs, köztük z lpverzióért, és z bból szármzttott speciális verziókéért. Nyilván kell trtni z egyes komponensek közül zokt csoportokt, melyek együtt mőködıképesek, beleértve hozzájuk trtozó követelményeket és követelménykövetési dokumentációkt. A konfigurációmenedzsmentnek biztosítni kell tudni, hogy minden idıpillntbn legyen egy mőködı konfiguráció. A konfigurációmenedzsment felelıs továbbá zért is, hogy vevıknek leszállított verziók konzisztensen rchiválv legyenek, így egy esetleges pnsz esetén vissz lehet keresni, hogy mi volt problém, és milyen fejlesztések történtek zót. A konfiguráció menedzsment tehát nemcsk fejlesztésnél és termék kiszállításnál fontos, hnem krbntrtási fázisnál is. A konfigurációmenedzsment egy hierrchikus folymt. Megkülönbözetünk konfigurációs komponenseket és konfigurációs egységeket 2.4 ábr. Komponens 1 v1.0 v1.1 v1.2 V2.0 Konfigurációs komponensek Komponens 2 Komponens 3 v1.0 v1.3 V2.1 v1.0 v1.1 v1.3 V1.6 V2.0 idı idı idı Konfigurációs egység Konfigurációs egység 1 Konfigurációs egység 2 v1.0 v1.0 v1.0 V1.6 v ábr A konfigurációs komponenseket és konfigurációs egységek viszony A konfigurációmenedzsment folymt lépései A konfigurációmenedzsment áltlábn z lábbi lépésekbıl áll: Résztvevı eszközök zonosítás A konfiguráció menedzsment fontos feldt, hogy zonosíts zokt termékeket, eszközöket, melyek együtt egy konfigurációt lkotnk. Fontos, konfiguráció menedzsment V2.1 idı Scherer Blázs (scherer@mit.bme.hu), 2010.

24 Rendszertervezés (VIMM238) 24 folymt mőködése fejlesztési iterációk ltt, hiszen egy termékbıl végleges verzió elıtt 3-4 fejlesztési verzió is készül. Ezek konfigurációit nyilván kell trtni, mert fontos lpot szolgálttnk következı verziókhoz, illetve nem ritkán folymtosn hsználtk fejlesztés során. A konfiguráció menedzsmentben részvevı eszközök kiválsztás z lábbi szempontok szerint szokott történni: Termékek, melyek kiszállításr kerülnek felhsználónk Termékek, melyek fontosk belsı munkfolymtokhoz és változhtnk z idıben. Eszközök, melyek z egyes munkfolymtokhoz kellenek A konfiguráció menedzsment lá következı termékeket, eszközöket szokás vonni: Követelmények és követelmény menedzsment dokumentumok A fejlesztési folymtok terve Termék specifikációk, interfész leírások Progrmkód Termékre vontkozó fejlesztési eredmények Tesztek, teszt tervek Fordító progrmok és fejlesztési környezetek Fontos zt is meghtározni, hogy fejlesztési folymt melyik stádiumábn és mikor kerüljön egy termék konfiguráció menedzsment folymt tevékenysége lá. A konfigurációmenedzsment rendszer létrehozás Gykorltilg z dtbázist, és konfiguráció menedzsment procedúrát kell létrehozni, és z ezek kezelésére szükséges eszközöket felállítni. Létrehozz konfiguráció menedzsmentben résztvevık hierrchiáját: Konfiguráció felügyelı, fejlesztı stb. Áltlábn 3 tárolási helye, szintje szokott lenni egy konfiguráció menedzsmentnek. Dinmikus: Helyben fejlesztınél tárolt verziók. Kontrolált, vgy központi tárolási pont: Központi tároló pontj jelenlegi fejlesztésnek. Sttikus, rchívum: A már kibocsájtott relese-ek rchívum. Változások követése, z integritás megtrtás A változások nyilvántrtásánál, zt is követni kell, hogy ki, mit, mikor és miért változttott. Továbbá változások egész rendszerre gykorolt htását is fel kell mérni. Tipikus ezzel kpcsoltos feldtok: A konfigurációs komponensek Revision history-j A változásokhoz trtozó log-ok krbntrtás A konfigurációs komponens állpotánk nyilvántrtás A relese-ek és fejlesztési utk közötti különbségek nyilvántrtás Konfigurációs uditok támogtás Scherer Blázs (scherer@mit.bme.hu), 2010.

25 Rendszertervezés (VIMM238) 25 Relesek kibocsájtás. A relese egy olyn kombinációj z egyes konfiguráció menedzsmentben résztvevı komponenseknek, melyek egy komplett konfigurációs egységet lkotnk. Konfigurációs egységeket és relese-eket nem csk teljes termékre lehet létrehozni, hnem részfolymtokr is, például rendszer tervre, specifikációkr. Ezeket konfigurációs egységeket áltlábn z egész fejlesztési cspt, hgyj jóvá, tehát megfelelı konfigurációs komponensek verzióink kiválsztás nem egy ember dolg A konfigurációmenedzsment és verziókövetés viszony A konfiguráció menedzsmentnek egyik legfontosbb eszköze verziókövetés, ugynkkor zt is fontos megjegyezni, hogy konfigurációmenedzsment jóvl több egyszerő verziókövetésnél. Miért szükséges verziómenedzsment? Aki vlh fogllkozott fejlesztéssel nnk következı problém vlószínőleg igen ismerıs: 1. Az eddig futó lklmzáshoz új kódrészletet rkunk. 2. Az lklmzás lefgy. 3. Visszállítjuk módosításokt. 4. Az lklmzás még mindig fgy Az ilyen szívások rengeteg idıt el tudnk rbolni, tehát érdemes vlmilyen megoldást tlálni rr, hogy dott esetben egy régebbi verzióhoz fájdlommentesen vissz tudjunk lépni fejlesztés során. Ezt hívjuk verziókövetésnek. A Triviális verziókövetés, vgy mire jó Totl Commnder A legtriviálisbb verziókövetés, hogy npont egy külön könyvtárb bemásoljuk z znpi munkánk eredményét. H ngyon kulturáltk krunk lenni, kkor project mellé mellékelünk egy chnge file-t is, miben leírjuk, hogy mit és miért változtttunk (2.5 ábr). 2.5 ábr Totl Commnder lpú verziókövetés Bár ez módszer minden elıismeret nélkül könnyen lklmzhtó, z lklmzás során számos problém, kérdés felmerül: A másoltok komplett másoltok, tehát sok helyet igényelnek. Milyen gykorisággl készítsünk másoltot? Csk mőködı verziót másoljunk fel, vgy köztes verziót is? Hogyn tudjuk követni, hogy min változtttunk? A chnge file-t ngyon pontosn kell nyilvántrtni, különben inkább kártékony, mint hsznos, de nincs semmilyen utomtizmus, mi erre ösztönözne. Scherer Blázs (scherer@mit.bme.hu), 2010.

26 Rendszertervezés (VIMM238) 26 Ezeknek kérdéseknek, problémáknk egy része áltlános és nem csk Totl Commnderes megoldásr specifikus. Ez módszer meglepıen htékony, mikor egyedül dolgozunk, de szinte teljesen hsznvehetetlenné válik, ngyobb csoport lpú fejlesztésnél: 1. Változttunk mőködı lklmzáson 2. De vlki más is beleír egy picit 3. Az lklmzás lefgy Az ilyen problémák orvoslásár jöttek létre verziókövetı rendszerek. Ezek segítségével egységesen nyomon tudjuk követni, hogy ki mikor, mit és miért változttott. A verziókövetı rendszerek lpfoglmi A verziómenedzsment lpj nem más, mint egy dott project összes változásánk nyilvántrtás. Egy verziómenedzsment rendszer nyilvántrt minden egyes file-on végrehjtott változttást, vlmint könyvtárstruktúrát érintı minden változást. A felhsználónk lehetısége vn megtekinteni project vgy egy file állpotát egy dott pillntbn, megtudni, hogy ki, mit és mikor változttott z dott projecten. A verziókövetı rendszerek beépített támogtássl rendelkeznek verziók mellé dott chnge log-ok nyilvántrtásához. A verzió követés lpfoglmi (2.6 ábr): Repository (rktár): Központi nyilvántrtás z dtoknk vgy projectnek ( mster copy). Client: Felhsználó, ki dolgozni kíván projecten. Working copy: Egy Client áltl projectbıl létrehozott munkváltozt, mit szbdon változttht. Repository Visszír (Commit) Olvs (Check out) Olvs (Check out) Client 1 Client 2 Client ábr A verziókövetı rendszerek lpfoglmi A verziómenedzsment rendszerekkel kpcsoltbn felmerülı elsı kérdés áltlábn, hogy hogyn támogtj felhsználók együttmőködését, úgy, hogy zok ne lépjenek egymás lábár? Ilyen strtégi nélkül könnyen elıfordulht, hogy egy file-t vgy projectet egyszerre többen módosítnk, mjd felülírják egymás módosításit ( módosítások nem tőnnek el, de nem is kerülnek bele z új verziób). Scherer Blázs (scherer@mit.bme.hu), 2010.

27 Rendszertervezés (VIMM238) 27 Lock-Modify-Unlock megközelítés Az elsı ilyen együttmőködési mechnizmus z ún. Lock-Modify-Unlock megközelítés volt. Ennek mőködése következı (2.7 ábr): Módosítás elıtt le kell lock-olni egy file-t. Tehát egyszerre csk egy ember tudj módosítni file-t. Olvsni tudj más is. Repository 1; 1; Lock Red User 1 Locl copy Repository 1; 1; 1; 1; User 1 Locl copy 1; 1; 3; 3; User 2 Locl copy 1; 1; X Lock User 2 Locl copy 1; 1; Repository 1; 1; 3; 3; Write Unlock User 1 Locl copy Repository 1; 1; 1; 1; 3; 3; 3; 3; 1; 1; 3; 3; Lock User 2 Locl copy 1; 1; Red User 2 Locl copy 1; 1; 3; 3; 2.7 ábr A Lock-Modify-Unlock megközelítés A Lock-Modify-Unlock megközelítésnek következı problémái vnnk: Adminisztrtív problémákhoz vezethet: H egy fejlesztı elfelejt ki lock-olni egy file-t, kkor más nem férhet hozzá. H szbdságr megy, kkor pl. rendszergzd kell lock feloldásához. Felesleges egymásr várást okozht. Egy C file-on belül például vlki z F1 függvényt krj módosítni, más vlki pedig z F2-t. Semmi köze kettınek egymáshoz mégsem tudják egyszerre megcsinálni. A biztonság hmis illúzióját keltheti. Például két fejlesztı dolgozik ugynzon projecten, z egyik lock-olj z A file-t, másik B file-t. A két file között függıség áll fent. Mindketten zt hiszik, hogy biztonságbn vnnk, holott mégsem. Scherer Blázs (scherer@mit.bme.hu), 2010.

28 Rendszertervezés (VIMM238) 28 A Copy Modify Merge megközelítés A Copy Modify Merge megközelítést (2.8 ábr) hsználj legtöbb mnpság is forglombn lévı verziókövetı rendszer (CVS, Subversion stb.) A megközelítés jellemzıi következıek: Egyszerre több fejlesztı is ki Check out -olhtj ugynzt. Mindenki sját Working copy-ját hsználj. Working copy: A Repository (vgy nnk egy részének) sját gépen tlálhtó leképezése. A létrejövı konfliktusokt pedig Merge-gel, tehát fuzionálássl oldják fel, és így hoznk létre egy új verziót. A Merge, bár támogtv vn verziókövetı rendszer áltl, lpvetıen mégis emberi döntéseket követel, tehát nem utomtikusn történik. Scherer Blázs (scherer@mit.bme.hu), 2010.

29 Rendszertervezés (VIMM238) 29 Repository 1; 1; Repository Check out 1; 1; 1; 1; User 1 Locl working copy 10; 10; Check Out Mindketten ki check out -olják file-t User 2 Locl working copy 1; 1; Mindketten módosítják User 2 Locl working copy 1; 1; 20; 20; Repository 10; 10; 3. User 1 4. Commit Locl working copy Repository 10; 10; 10; 10; User 1 Locl working copy 10; 10; User 1 végzett, feltölti módosításokt User 2 Locl working copy 1; 1; 20; 20; X Commit User 2 nem tudj feltölteni módosításokt, mert z ı locl working copy-j nem up-todte User 2 Locl working copy 1; 1; 20; 20; Repository 10; 10; User 1 Locl working copy Repository 10; 10; 10; 10; User 1 Locl working copy 10; 10; Edit conflicts User 2 Locl working copy User 2 Locl working copy User 2 összeveti változásokt sját verziójávl 10; 10; 1; 1; 20; 20; User 2 merge-el 10; 10; 20; 20; Repository 10; 10; 20; 20; 7. User 1 Locl working copy 10; 10; Repository 10; 10; 20; 20; 8. Updte User 1 Locl working copy 10; 10; 20; 20; Commit User 2 feltölti z új verziót User 2 Locl working copy 10; 10; 20; 20; User 1 Updte-eli mgát legfrissebb verzióhoz User 2 Locl working copy 10; 10; 20; 20; 2.8 ábr A Lock-Modify-Unlock megközelítés A Copy Modify Merge megközelítés tuljdonsági összefogllv következık: Egyszerre több fejlesztı is dolgozht ugynzon kódon. Commit-nél z esetleges konfliktusok kiderülnek. Scherer Blázs (scherer@mit.bme.hu), 2010.

30 Rendszertervezés (VIMM238) 30 Embereknek kell döntenie konfliktus feloldásáról. Ngyon fontos zt hngsúlyozni, hogy verziókövetı rendszer nem helyettesíti z emberek közötti kommunikációt. Csk segít tisztánlátásbn és munkfolymtok követésében. A jó kollegiális viszonyr mindenképpen szükség vn, nélkül semmi sem mőködik. Ez Copy Modify Merge megközelítés ugynkkor nem hsználhtó minden fejlesztésben résztvevı termékre, dokumentációr. A Lock lehetısége ugynúgy benne vn modern verziókövetı rendszerekben, mint elıdjeiknél. A Lock megközelítést kell hsználni például olyn bináris jellegő file-ok esetében, hol merge nem megoldhtó (hngfile-ok, bináris fileok, NYÁK-tervek, kpcsolási rjzok, stb.) A Törzs ág, Cimkézett ágk, és Elágzások vgy Trunks, Tgs és Brnches Egy komplex project verziókövetése során nem csk z egyes file-ok verzióit, hnem z egész project konfigurációját nyomon kell követni (2.9 ábr). Egy project esetében három ehhez kpcsolódó foglmt kell megjegyezni: Trunks: Ez z ág trtlmzz project törzsét, tehát hivtlos fejlesztési irányt. Brnch: Az elágzások project fejlesztési irányától kicsit eltérı funkciók kipróbálásár, megvlósításár szolgálnk. A lényege z, hogy ilyenkor fejlesztés eredeti menete ne bonyolódjon, hnem egy sját leágzást lehessen nyúzni. Az esetek többségében z elágzások visszintegrálódnk z eredeti projectbe. Tgs: A címkézett ág felel meg z egyes stbil és mőködıképes relese-eknek. Egy project fejlesztése során idırıl idıre szoktk ilyen relese verziókt létrehozni. Ez zért fontos, mert Trunk ág folymtos fejlesztésben vn, és így áltlábn nem trtlmz komplett és jól mőködı verziót. Vn úgy, hogy Trunk ág éppen el sem tud indulni, vgy nem is fordul le. Brnch Trunk Brnch merge Megszkított oldlág Tg ábr Egy project verziókövetési életciklus Scherer Blázs (scherer@mit.bme.hu), 2010.

31 Rendszertervezés (VIMM238) A rendszertervezés fejlesztési folymti 3.1. A fejlesztési folymtok életciklus modelljei A mőszki világbn számos fejlesztési modell terjedt el z évek során. Ez fejezet röviden átveszi mérnöki folymtok végrehjtásár hsznált legelterjedtebb életciklus modelleket. Mielıtt zonbn ismertetnénk ezeket modelleket fontos megjegyezni, hogy bemuttott modellek mindegyike csk útmuttó információkt trtlmz. Az, hogy hogyn hjtnk végre egy ilyen fejlesztési modellt mindig z dott cégtıl függ. Nem véletlenül tárgylj szinte mindegyik ilyen jellegő módszertn z dott modell testreszbását. Tehát, ne lepıdjünk meg, hogyh máshol egy picit eltérıen nevezik lépéseket, vgy nem teljesen z áltlunk bemuttott lépéseket hjtják végre A Vízesés modell A rendszertervezés egyik elsı fejlesztési modellje z ún. vízesés modell [3.1] volt, melyet 1970-ben publikáltk (3.1 ábr). Követelmény nlízis Requirement nlysis Rendszertervezés System design Részletes tervezés Detiled design Implementáció Implementtion Modul teszt Modul test Integráció és teszt Integrtion & test 3.1 ábr A vízesés modell egyik lehetséges formáj Krbntrtás Mintennce A vízesés modell gykorltilg formáb önti z egyes életciklus lépéseket. A lépések formlizáltk, sorrendjük kötött. Csk z egyik lépés után hjthtó végre másik. Hátrány, hogy nem jól lklmzhtó zokbn z esetekben, hol követelmény nem elıre jól megdott. A vízesés modell további hátrány, hogy nem jelzi párhuzmot tervezési és teszt lépések között, illetve nincs tisztázv viszony z iterációkkl A Spirál modell A spirl modelt [3.2] Boehm publikált 1986-bn. A Spirál modell egy erısen itertív jellegő megközelítés. Az egyes fázisok után olyn prototípusok állnk rendelkezésre, melyek megrendelıvel vló egyeztetés lpján segítenek meglpozni következı prototípust, mjd végül kész rendszert. A Spirál modell elsısorbn ott hsználhtó, hol követelmények és kívánlmk nem állnk projekt elején rendelkezésre, így z egyes prototípus fázisoknál lehetıség vn zoknk pontosításár. Gykrn lklmzzák olyn területeken is, hol z egyes prototípusok hsználtávl ngy megbízhtóságú rendszert krnk létrehozni. A Spirál modell htározott hátrány, hogy ngyon tpsztlt vezetı kell hozzá, illetve egyáltlán nem bánik gzdságosn z erıforrásokkl. Scherer Blázs (scherer@mit.bme.hu), 2010.

32 Rendszertervezés (VIMM238) 32 A Spirál modell fázisi (negyedei) (3.2 ábr): 3.2 ábr A Spirál modell Determine Objectives, Alterntives, nd Constrints (A célok, lterntívák és megkötések zonosítás) Ennek negyednek fı funkciój, hogy zonosíts termék/projekt céljit, mind funkcionlitás, mind teljesítmény vontkozásábn. Felméri megvlósítási lterntívákt (új rendszer tervezése, meglévı komponensek hsznált stb.) Evlute Alterntives, Identify, Resolve Risks (z lterntívák kiválsztás, z lterntívák kockáztink zonosítás) Kiválsztj legjobb megoldásokt, melyek céloknk legjobbn megfelelnek, és megvizsgálj zok kockáztit. A legjobbnk tőnı lterntívához prototípust készít. Ezekkel z itertív prototípusok áltl feltérképezhetı és kipróbálhtó kockázt megelızı megoldásokkl igyekszik modell végtermék kockáztink lehetı legteljesebb kivédésére. Develop, Verify, Next-Level Product (Fejlesztés, ellenırzés, következı termék elıkészítése) A következı fázisnk megfelelı termék kiválsztás, és következı fázis elıkészítése. H z elızı prototípus már teljesen mőködı verzió volt, kkor egy vízesés modellszerő fejlesztés befejezése. Next Phses (A következı fázis) A következı lépés és nnk ütemének megtervezése A V-modell Az 1997-ben megjelent V-modell [3.3] (3.3 ábr) gykorltilg vízesés modell továbbfejlesztése: fontos és látványos eltérés tesztelési ág visszhjtás. Ezzel zonos hierrchi szintre emelkedtek z összetrtozó tesztelések és tervezések. A legtöbb beágyzott rendszereket fejlesztı cég ezt modellt lklmzz. Scherer Blázs (scherer@mit.bme.hu), 2010.

33 Rendszertervezés (VIMM238) 33 Követelmény nlízis és Logiki rendszer terv. Requirement nlysis Rendszer szint Rendszertervezés, Techniki rendszer spec. System design Rendszer Integráció és teszt System Int. & test Felhsználói teszt User cceptnce test Alrendszer szint Részletes tervezés Subsystem design Alrendszer Integráció és teszt Subsystem Int. & test Modul szint Modul tervezés Module design Modul teszt Modul test Implementáció Implementtion 3.3 ábr A V-modell A rendszer egyik ngy elınye fejlesztési bsztrkciós szintek bevezetése, és z zonos bsztrkciós szinthez trtozó teszt és fejlesztési lépések összekpcsolás (késıbb látni fogjuk ennek megvlósítását). Mielıtt elkezdenénk V-modell lépéseinek részleteivel fogllkozni, ismerkedjünk meg nnk vlóságbn vló hsználti módjávl. Hierrchi szintek Minden rendszer tervezésénél z elsı feldt rendszer hierrchikus bsztrkciós szintekre vló bontás (3.4 ábr). Ezek végigkísérik tervezés folymtát, és z egyes lépések z bsztrkciós szintekhez trtozó tervezési folymtokt fogják megdni. Scherer Blázs (scherer@mit.bme.hu), 2010.

34 Librries interrupts Exceptions Kernel Hrdwre Abstrction Lyer Hrdwre független mitmót API Device Drivers Seril I/O kezelés SPI I2C Rendszertervezés (VIMM238) 34 Rendszer szint Alrendszer szint Anlóg I/O Digitális I/O Vezérlı Comm Node szint Librries ISO C Mth Appliction Hrdwre független mitmót API DPY-TRM COM-R04 MIKROP Vezérlı szoftver szint Kernel Hrdwre Abstrction Lyer Device Drivers MCU-ARM API I/O kezelés interrupts Exceptions Seril SPI I2C Hrdwre 3.4 ábr Rendszertervezési bsztrkciós szintek (nem teljes) Az bsztrkciós szintekre vló bontás után érezhetı, hogy nincs olyn fejlesztési modell, mi elágzás nélkül végig tudná követni ezt sok szintet. Azért, hogy gykorltbn ezeket, modelleket hsználni lehessen, legtöbb esetben fejlesztési modell z egyes szinteken külön ágkr, külön feldtokr osztódik szét. Ezeknél f jellegő elágzásoknál történik meg tipikusn feldtok lválllkozóknk, fejlesztési csoportoknk vló kidás is (3.5 ábr). Rendszer szint Alrendszer szint Anlóg I/O Digitális I/O Vezérlı Comm Node szint ISO C Mth Appliction DPY-TRM COM-R04 MIKROP Vezérlı szoftver szint MCU-ARM API Hrdwre Implementáció 3.5 ábr A rendszertervezési folymt feldtokr bontás tervezési szkszbn és összeintegrálódás tesztelési/integrálási szkszbn Scherer Blázs (scherer@mit.bme.hu), 2010.

35 Rendszertervezés (VIMM238) 35 Például: Egy utógyár rendszerszinten megtervezi egy gépkocsi elektronikáját. Az egyes belsı csoportjink kidj z lrendszerek, mint erıátvitel, komfortelektronik, stb. részletes tervezését. Az egyes csoportok specifikálják node-ok megvlósítását, mjd kidják zokt lválllkozóknk. Miután z lválllkozók megcsinálták és tesztelték node-okt, csoportok integrálják zokt lrendszerekké és tesztelik zokt. Végsı lépésként pedig rendszertervezı csoport összeállítj z lrendszerekbıl teljes rendszert és teszteli zt. A (3.4 ábr), (3.5 ábr) segítségével bemutttuk, hogy fejlesztési folymt milyen hierrchi szintekre oszthtó és hogyn bomlik részfolymtokr. Ahhoz zonbn, hogy z ilyen modell vlóságbn is mőködjön fontos figyelembe venni olyn prktikus tpsztltokt, mint például, hogy vlóságbn elsıre sohsem készül tökéletes rendszer. Tehát modellnek, vgy nnk gykorlti végrehjtásánk lehetıséget kell dni vlmilyen iterációr. Az iprbn egy termék elkészítésénél tipikusn 3-4 iterációs ciklussl számolnk. Ezt modern fejlesztési modellek már figyelembe veszik. Például V-modell XT már trtlmz Iterációk tervezése lépést (ez nem integrális része z lp V-modellnek). A (3.6 ábr) egy tipikus V- modell lklmzási gykorltot mutt be. Indítási fázis 5-6 hónp Tervezési fázis hónp Elıkészítési fázis 7-8 hónp Megegyezési fázis 7-8 hónp Megerısítési fázis hónp Érlelési fázis 8 hónp Sorozt- -gyártás Szoftver fejlesztés 4. Iteráció Krbntrtás Logiki rendszer rchitektúr tervezése 3. Iteráció Rendszerkoncepció (logiki rendszerterv) Techniki rendszer rchitektúr tervezése SIL réteg meghtározás 2. Iteráció Rendszer specifikáció Techniki rendszerterv 1. Iteráció 3.6 ábr Egy tipikus projectfejlesztés V-modell lpján 3.2. A V-modell tervezési lépései Ez fejezet V-modell tipikus fejlesztési lépéseit tekinti át. Az egyes lépéseket úgy htározzák meg, hogy mindig vlmilyen jól megfoglmzhtó végtermék álljon elı lépés végén. Ezeket végtermékeket szkzsrgonbn rtifct-nek szokták nevezni Követelménynlízis, és Logiki rendszerterv elkészítése A Követelménynlízis, és Logiki rendszerterv lépés (3.7 ábr) ngol neve: Anlysis of system reqirements nd specifiction of logicl system rchitecture. Scherer Blázs (scherer@mit.bme.hu), 2010.

36 Rendszertervezés (VIMM238) 36 A lépés elsı feldt, hogy felmérje és elemezze felhsználói követelményeket. Az esetek többségében bemenı felhsználói követelményeket Requirement development folymt biztosítj. Ennek lépésnek feldt, hogy megtlálj követelményekben rejlı inkonzisztenciát, illetve mőszki nyelvre fordíts le felhsználó igényeit. Sokszor elıfordul ugynis, hogy mit felhsználó követelménynek gondol, z vlóságbn nem z, és neki egészen másr vn szüksége. Például egy tipikus rossz felhsználói követelmény, hogy 24bites AD-t hsználjunk. Ez vlóságbn nem feltétlenül jelenti zt, hogy felhsználónk vlóbn 24-bites AD-r vn szüksége (áltlábn nincs is tisztábn zzl, hogy ez mit jelent pontosn), hnem zt jelenti, hogy vlmilyen értéket ı egy dott pontossággl kr mérni. Az már egy mőszki kérdés, hogy ez hogy megvlósíthtó (jelkondicionálás + 16 bites AD stb.), de nem követelmény. Felhsználói követelmények Teszt eredmények (A V modell másik ágából) Kpcsolt tesztelési ággl A felhsználói követelmények nlízise A logiki rendszerchitektúr specifikálás Logiki rendszerterv Hsználti Mintpéldák (A tesztelés számár) Kpcsolt tesztelési ággl 3.7 ábr A felhsználói követelmények nlizálás és logiki rendszer rchitektúr megtervezése A lépés második feldt, hogy megismert felhsználói igények lpján elkészítsék rendszer logiki vázát, rendszertervét. A fı cél rendszert lkotó logiki egységek és funkcióik, interfészeik feltárás, definiálás. A logiki rendszerrchitektúr semmilyen megvlósítási részletkérdéssel nem fogllkozik. Csk zzl, hogy milyen tuljdonságú rendszer fog létrejönni. Röviden összefogllv logiki rendszerrchitektúr z lábbi két dolgot trtlmzz: Definiálj zokt tuljdonságokt, funkciókt, mikkel rendszer rendelkezik Definiálj zokt tuljdonságokt, funkciókt, mikkel rendszer nem rendelkezik Természetesen z ilyen logiki rendszerrchitektúrák létrehozásánál szöveges leíráson kívül különféle modellezési eszközöket is hsználnk, elsısorbn z UML lpú leírások közkedveltek. A legtöbb esetben z UML Use Cse, Clss, Interction digrmmjit hsználják erre célr (Az UML digrmokt z elızı féléves Beágyzott rendszerek szoftvertechnológiáj vimim150 tárgybn okttták). Fontos megjegyezni lépéssel kpcsoltbn, hogy logiki rendszer rchitektúr mellett egy hsználti példák (use cses) rtifct-et is létrehoz. Ez zért kiemelten fontos, mert ezek felhsználási példák teremtenek kpcsoltot késıbb tesztelési ággl. Ez dokumentáció fogj rendszer és végfelhsználói tesztek lpjit jelenteni. Scherer Blázs (scherer@mit.bme.hu), 2010.

37 Rendszertervezés (VIMM238) 37 A 3.7 ábrán megfigyelhetı z iterációr vló felkészülés is. Egy esetleges iterációnál felhsználják tesztek eredményeit, és z elızı ciklusbn létrehozott rendszertervet. Fontos zonbn megjegyezni, hogy gykorlti lklmzásbn igyekeznek ezt lépést úgy megvlósítni, hogy iterációr ne legyen szükség, hiszen egy ezen ponton történı változttás z összes hierrchiábn lcsonybb szinten álló folymt újrgondolását hozz mgávl. Például, 3.6 ábrán megfigyelhetjük, hogy logiki rendszerterv hozzávetılegesen z elsı év végére elıáll, és után már kötöttnek tekintett. Ez egy normál fejlesztésnél megoldhtó így, hiszen tudjuk, mit krunk létrehozni, ngy funkció módosításr már nem lesz szükség, kisebb specifikáció változttásokt pedig requirement mngement folymton keresztül le lehet kezelni A logiki rendszer rchitektúr elemzése, techniki rendszer rchitektúr specifikációj A logiki rendszer rchitektúr elemzése, techniki rendszer rchitektúr specifikációj lépés ngol neve: Anlysis of logicl system rchitecture nd specifiction of technicl system rchitecture. A logiki rendszerrchitektúrából kiindulv techniki rendszer rchitektúr hozz létre rendszer techniki vázát. A lépés feldt, hogy z egyes logiki funkciókt elossz tényleges fiziki modulok között (3.8 ábr). Funkció 1 Funkció 2 Logiki rendszer rchitektúr Funkció 3 Funkció 4 Funkció 3 Funkció 3.1 Funkció 3.2 Funkció 3.4 Funkció 3.3 Funkció 3.5 Node 2 Szenzor Jelkondítcionálás AD konverzió Mikrovezérlı softwre Feldolgozás Klibrálás Kommunikáció Comm interfész Anlóg kimenet Bevtkozó 3.8 ábr A logiki rendszer rchitektúr leképezıdése techniki rendszer rchitektúrává Ebben lépésben történik meg techniki lrendszerek további finomítás és lcsoportokr bontás, vlmint szoftver és hrdver folymtok különválsztás és specifikálás is. Fontos megjegyezni, hogy mikor logiki rendszerrchitektúrát leképezzük techniki rendszerrchitektúrává, kkor egy logiki funkció többnyire nem egy fiziki egységgé fog leképzıdni. Áltlábn egy fiziki egység több logiki funkciót vlósít meg, vgy fordítv. Tehát leképezés tipikusn nem 1:1, éppen ezért is különböztetik meg két lépést. Scherer Blázs (scherer@mit.bme.hu), 2010.

38 Rendszertervezés (VIMM238) 38 Arr, hogy logiki rendszerrchitektúrából hogyn kell techniki rendszerrchitektúrát létrehozni, nem lehet minden körülmények között érvényes útmuttót dni, hiszen minden rendszer más, ezért leképezés módszerei különbözıek lehetnek. Az lábbikbn egy igen széleskörően, elsısorbn komplett rendszereknél hsználhtó leképezési lépéssoroztot muttunk be (3.9 ábr). Logiki Rendszerterv (funkciók, interfészek, követelmények) Teszt eredmények (A V modell másik ágából) Kpcsolt tesztelési ággl Szbályozások elemzése Szbályozási körök specifikációj A logiki rendszerterv nlízise Rel-time követelmények feltérképezése A techniki rendszerterv specifikálás Rel-time követelmények specifikációj Elosztott mőködés elemzése Hálóztok, elosztott rendszerek specifikációj Biztonsági és megbízhtósági elemzés Biztonsági és megbízhtósági specifikációk Techniki Rendszerterv (techniki komponensek, interfészek, követelmények) Teszt esetek (A tesztelés számár) Kpcsolt tesztelési ággl 3.9 ábr A logiki rendszerrchitektúr elemzése és techniki rendszerrchitektúr specifikálás A szbályozási körök elemzése és specifikációj Amikor egy techniki rendszerrchitektúrát specifikálunk, kkor legtöbb esetben elıször is felmérjük rendszerben tlálhtó szbályozási köröket. Legyenek zok nyílt, vgy zárt hurkúk (3.10 ábr). Erre zért vn szükség, mert szbályozási körök felmérése során meg tudjuk állpítni, hogy mit és milyen pontossággl kell mérnünk, bevtkozásnk milyen pontossággl kell végrehjtódni. Továbbá be és kimenetek elemzésén túl lehetıségünk vn nnk meghtározásár is, hogy z egész folymt meddig trtht, tehát milyen rel-time követelményeknek kell megfelelnünk, hogy z dott szbályozás stbil legyen. A szbályozások feltérképezése során lehetıségünk vn képet lkotni szükséges elosztottság mértékérıl, tehát késıbb specifikálndó hálózti elrendezésrıl és számítási kpcitásról is. Gykorltilg ez lépés bból áll, hogy logiki rendszertervben 3.10 ábrán láthtóhoz hsonló vezérlési köröket keresünk, zonosítjuk zok komponenseit és felmérjük komponensekhez, vlmint z egész rendszerhez trtozó techniki prmétereket, igényeket. Scherer Blázs (scherer@mit.bme.hu), 2010.

39 Rendszertervezés (VIMM238) 39 Emberi bevtkozás Környezet Rendszer Bevtkozási Interfész Vezérlési lgoritnus Bevtkozó Szenzor 3.10 ábr Egy áltlános szbályozási/vezérlési kör blokkvázlt --lgoritmus Sok esetben, hol szbályozási kör komplex, mint például egy motorvezérlı elektronikánál viselkedést már ebben stádiumbn nlizálják vlmilyen modellezı eszköz, mint például Mtlb Simulink segítségével (dott esetben h ezt megbízhtósági elemzés is indokolj prototípus készítést is végeznek). Már ezen ponton elkezdıdik tényleges hrdver figyelembe vétele, hiszen digitális rendszerek tuljdonságukból dódón mindenképpen diszkrét idısorokon lpuló szbályozást vlósítnk meg. Figyelembe kell venni mikrovezérlık véges feldolgozási sebességét, beleértve kisebb számábrázolási felbontásból eredı kerekítési hibákt, z AD átlkítók késleltetését, nemlinerítását stb. Ez lépés egyben elıkészíti következı, rel-time követelményeket elemzı lépést. Rel-time követelmények feltérképezése és specifikációj A szbályozási hurkok meghtározás után rendszer mintvételezési és regálási ideje elemezhetıvé és specifikálhtóvá válik, így össze lehet állítni z egész rendszerre vontkozó idızítési követelményeket, mik ztán lebonthtók z egyes részegységekre vontkozó követelményekre. Az idızítési viszonyok vizsgált szolgál lpul késıbbi döntéseknél, mikor meghtározzuk mind z implementálásnál hsznált hrdvert, mind kommunikációs hálóztot, mind z olyn szoftver csomgokt, mint pl. rel-time operációs rendszerek. Az elemzés célj gykorltilg vezérlési/szbályozási kör egyes részeire idıkorlátok dás. Az összes folymtot tekintve szokásos megállpítndó prméterek: végrehjtási idı (execution time), válszidı (response time), htáridı (dedline), ktivitási rát (ctivtion rte) (3.11 ábr). Scherer Blázs (scherer@mit.bme.hu), 2010.

40 Rendszertervezés (VIMM238) 40 Aktiváció Aktivitási rát (ctivtion rte) Aktiváció Végrehjtási idı (execution time) Tsk / folymt Tsk / folymt Válszidı (response time) Htáridı (Dedline) 3.11 ábr Reltime követelmények prméterei Azt, hogy z egyes folymtokr hogyn kell rel-time krkterisztikát megállpítni z elızı féléves: Vlós idejő és biztonságkritikus rendszerek (VIMIM151) tárgyból elsjátíthttuk. Elosztott mőködés elemzése, z elosztott rendszerek és hálóztok specifikálás A rel-time idızítések és szbályozási követelmények ismeretében rendszer funkciói szétosztásr kerülnek z egyes node-ok, egységek között. Tehát ténylegesen specifikáljuk, hogy melyik funkciót melyik hrdver egység és hol hjtj végre. Ahhoz, hogy ezt megtegyük elıször elemezni kell, hogy mely mőveletek párhuzmosíthtók, illetve melyeket lehet és célszerő fizikilg nem egy helyen, hnem elosztottn végrehjtni. Amikor ezek kiválsztásávl végeztünk, kkor specifikálni kell kommunikációs hálóztot, hálóztokt, mely z egyes különálló hrdvereken mőködı funkciókt összeköti. Gykorltilg ennél lépésnél már kár hálózt típusát is ki lehet válsztni, hiszen már minden prmétert tudunk hhoz, hogy hálózttól elvárt átviteli sebességet meg tudjuk htározni. A küldött, fogdott üzeneteket és zok gykoriságát is specifikálni lehet már. Összegezve tehát rendszer funkciók csomópontokr (node)-r vló felosztását illetve kommunikációs mátrix meghtározását végezzük ezen ponton. Itt node-ok meghtározásánál kell rr törekedni, hogy már meglévı komponenseket újrfelhsználjunk, h lehetséges. Amennyire lehet, gondot kell rr is fordítni, hogy létrejövı új node-okt késıbb lehetı legtöbb helyen lehessen lklmzni, újrfelhsználni. Tehát, sokszor ehhez ponthoz trtozik rendszer modulritásánk megtervezése is. A megbízhtóság és biztonság szempontjából fontos részek zonosítás A beágyzott rendszerek jelentıs részénél biztonságosság és megbízhtóság lpkövetelmény, így már tervezés elején figyelembe kell ezeket venni. A techniki rendszerrchitektúr tervezése ezért trtlmz egy biztonsági és megbízhtósági nlízist, mely meghtározz késıbbi fejlesztési lépésekben lklmzott eszközöket és módszereket. Ez biztonsági és megbízhtósági nlízis 3.12 ábrán bemuttott lépésekbıl áll. Scherer Blázs (scherer@mit.bme.hu), 2010.

41 Rendszertervezés (VIMM238) 41 Logiki Rendszerterv (funkciók, interfészek, követelmények) Veszély nlízis Megbízhtósági biztonsági nlízis Veszélyt jelentı szituációk Kockázt, Hib típusok, Hib gykoriság elemzés Megbízhtósági, biztonsági követelmények (SIL) A megbízhtóság szempontjából fontos komponensek feltérképezése Biztonság, megbízhtóság kritikus komponensek Biztonság, megbízhtóság kritikus eljárások, rendszerek specifikációj A verifikációs-vlidációs lépések specifikációj Egyes egységek rendszerek követelményeinek specifikálás A softwre fejlesztési folymt követelményeinek specifikálás Verifikációs vlidációs eljárások Hrdwre specifikus megbízhtósági biztonsági követelmények Softwre specifikus megbízhtósági biztonsági követelmények Softwre fejlesztési folymt 3.12 ábr A biztonságossági és megbízhtósági nlízis lépései A biztonságossági és megbízhtósági nlízis elsı lépése, hogy felmérjük rendszerre vontkozó lehetséges veszélyhelyzeteket. Miután veszélyes szituációkt ismerjük, elemzésre kerül z ezek áltl jelentett kockázt is. Risk (kockázt): Vlminek kockáztát nem lehet egzkt módon megdni, kockázt megdásr legelfogdottbb mód, hogy bleset vlószínőségét és z ebben z esetben bekövetkezı kár mértékének szorztát vesszük. R Probbility of Accident * Accident dmge A káron itt összevonv értünk emberi sérülést és nygi, környezeti kárt. A kockázt meghtározás szerves része, hogy meghtározzuk veszélyeket kiváltó hibákt és zok gykoriságát is. Miután rendszerre vontkozó kockáztot felmértük, meg kell htároznunk z egész rendszer hibtőrési szintjét is. Ez tipikusn z ún. limit-risk, vgy kockázti htár megtlálásávl kezdıdik. Limit Risk (kockázti htár): A kockázti htárt szintén nem lehet egzkt módon meghtározni (függ htályos törvényektıl, pici pozíciótól stb.), legjobb definíció rá, hogy egy olyn optimum, hol rendszer költsége (redundáns vezérlı stb.) és rendszer mőködésének költsége (kártérítési perek, visszhívások) együttesen minimumot dják 3.13 ábr. Scherer Blázs (scherer@mit.bme.hu), 2010.

42 Rendszertervezés (VIMM238) 42 hibtûrés költsége eredõ rendszer költség mûködési költség optimum 3.13 ábr A limit-risk megtlálás hibtûrés mértéke Természetesen ezt z optimumkeresési folymtot különbözı szbványok támogtják. Például z IEC61508-s szbvány áltl specifikált SIL (Sfety Integrity Level) rétegek egy ilyen besorolást nyújtnk (érdemes megjegyezni, hogy ezt nemzetközi IEC s szbványt csk 1998-bn dolgozták ki). A SIL legelterjedtebben lklmzott megbízhtósági besorolási mód. Gykorltilg mindenhol ezt hsználják és késıbbi fejlesztési lépések z itt megállpított szintektıl függenek. A SIL rétegek meghtározásánk egy módját 3.14-es ábr muttj be. kár mértéke Könnyő személyi sérülés, lcsony nygi kár Ismétlıdés esélye Ritkán ismétlıdı Több súlyos sérülés, szituáció vgy egy ember hlál, jelentıs, de átmeneti természeti kár Rendszeresen ismétlıdı szituáció Veszély esetén kár elkerülésének lehetısége Elkerülhetı, bizonyos esetekben Nem kerülhetı el Elkerülhetı, bizonyos esetekben A kiváltó veszélyes esemény bekövetkezésének vlószínősége Mgs Számottevı Minimális Több ember hlál, jelentıs hosszú távú környezeti károsodás Ktsztróf, ngy számú áldozt Ritkán ismétlıdı szituáció Rendszeresen ismétlıdı szituáció Nem kerülhetı el ábr A SIL réteg meghtározásánk egy módj Scherer Blázs (scherer@mit.bme.hu), 2010.

43 Rendszertervezés (VIMM238) 43 Miután meghtároztuk rendszerre jellemzı megbízhtósági szintet következı feldt gyengepontok felderítése, hol szükséges redundnci specifikálás. Ez gykorltilg techniki rendszerterv elején zonosított szbályozási, vezérlési körökön lpul. Lényege, hogy ezeknek köröknek z elemeit, egyes komponenseit vizsgáljuk szokásos megbízhtósági nlízis módszerek segítségével. Ilyen megbízhtósági nlízis módszer például BOOLE modell lpján, párhuzmos, illetve soros rendszer összetevık segítségével végzett számítások. Egyéb - például Mrkov láncokon lpuló - módszereket is gykrn hsználnk ennél lépésnél. (Ezek itt nem kerülnek ismertetésre, mert múlt féléves tárgyknál számtln ilyen példávl tlálkozhttunk. Az egyes komponensek, mint processzorok, diódák meghibásodási tényezıit gyártóktól lehet megszerezni). Ez megbízhtósági nlízis kimuttj, hogy mely rendszerkomponenseknél kell különösen odfigyelni. Fontos itt megjegyezni, hogy SIL szintet nem csk rendszerhez, de komplexebb rendszerkomponensekhez is szoktk rendelni. Ehhez nyújt segítséget, mikor meghtározzuk z egész rendszer, illetve z egyes komponensek megbízhtósági prmétereit. A megbízhtósági nlízis, illetve SIL besorolás további lépéseket erısen befolyásolni tudj. A 3.15-ös ábrán láthtjuk, hogy számos késıbbi fejlesztési lépés, mint szoftverfejlesztési módszerek, verifikációs és vlidációs eljárások függnek ettıl besorolástól. Minden cégnél vn rr vontkozó utsítás, hogy milyen SIL szinten milyen fejlesztési módszereket kell hsználni. Példként 3.15 ábr bemuttj egy cég fejlesztési szbályit SIL réteg besorolás függvényében. A cég csk SIL3-ig terjedı rendszerekkel fogllkozik (SIL4 már csk repülıkben és tomerımővekben hsznált rendszerekre jellemzı). Tevékenység SIL0 SIL1 SIL2 SIL3 A funkcionális követelmények belsı csoport szintő átbeszélése A funkcionális követelmények külsı személy áltli ellenırzése Prototípus készítés Simuláció Hib ok digrmmok készítése Vezérlési folym nlízis Adt folym nlízis Jelmgyrázt: "-": tilos "0": nem szükséges "+": jánlott "++": kötelezı 3.15 ábr. A tervezés egyes munkfolymti SIL réteg függvényében (péld) A techniki rendszer rchitektúr tervezésénél figyelembe kell venni zokt megkötéseket is, melyeket vgy törvény ír elı, vgy z lklmzott gyártási technológi szb meg Szoftver követelmények elemzése és szoftver rchitektúr megtervezése A Szoftver követelmények elemzése és szoftver rchitektúr megtervezése lépés ngol neve: Anlysis of softwre requirements nd specifiction of softwre rchitecture. A techniki rendszer rchitektúr megtervezése után fejlesztési folymt szétválik hrdwre, softwre, mechnik irányb (3.5 ábr). Mi itt részletesebben szoftver fejlesztési ággl fogllkozunk, tárgy késıbbi része tér ki hrdver ágr. Scherer Blázs (scherer@mit.bme.hu), 2010.

44 Rendszertervezés (VIMM238) 44 A techniki rendszer rchitektúr megtervezésénél elıálltk szoftverre vontkozó követelmények. Ez szoftver szempontjából nnyit, tesz, hogy z egyes feldtok hozzá lettek rendelve mikrovezérlıkhöz és meghtároztuk z egyes feldtok kommunikációs interfészét is. A szoftver rchitektúr tervezése lépés ezek után specifikálj zokt szoftver funkciókt, melyek vezérlıkön belül bementi dtokból elıállítják kimeneti dtokt. A szoftver rchitektúr tervezése z lábbi részfeldtokból áll: A szoftver rendszer htárink specifikációj A szoftver komponensek és zok interfészeinek specifikációj (nem trtlmzz z egyes komponensek részletes specifikációját, csk zt, hogy rendszer milyen komponensekbıl áll és zoknk mi kpcsolt) A szoftver rétegek specifikációj. A szoftver mőködési módjink specifikációj. Mgát tervezési folymtot ábr szemlélteti. Softwre Követelmények (Softwre-Hrdwre interfészek) Teszt eredmények (A V modell másik ágából) Kpcsolt tesztelési ággl Softwre követelmények elemzése A softwre rchitektúr specifikálás Softwre komponensek és interfészek specifikálás Softwre rétegek specifikációj Softwre mőködési módok specifikációj Softwre rchitektúr Teszt esetek (A tesztelés számár) Kpcsolt tesztelési ággl 3.16 ábr A softwre követelmények nlízise, softwre rchitektúr megtervezése Szoftver komponensek és zok interfészeinek definíciój A szoftver rchitektúr tervezésének elsı lépése, hogy zonosítjuk rendszer szoftver komponenseit és zok interfészeit. Ennek lépésnek z elsı munkszksz szoftver rendszer htárink pontos definiálás (3.17 ábr). Mi z, mit szoftver rendszer témkörébe trtozik, pontosn mit fog megvlósítni szoftver? Ez gykorltilg nem más, mint szoftver követelmények dokumentációbn tlálhtó specifikációjánk elemzése. Scherer Blázs (scherer@mit.bme.hu), 2010.

45 Rendszertervezés (VIMM238) 45 Szenzor Node 2 Jelkondítcionálás AD konverzió Mikrovezérlı softwre AD device driver Kommunikáció Vezérlés Klibrálás Comm Device driver DA driver Comm interfész Anlóg kimenet Bevtkozó 3.17 ábr Egy vezérlı szoftver htárink megállpítás és belsı szoftver funkciók zonosítás (ngy része direktben dódik z elızı lépésekbıl) A szoftver komponensek meghtározásánál, és z interfészek specifikálásánál legtöbbször UML lpú formlizált leírást lklmznk. Ennél lépésnél elsısorbn Clss digrmm hsználhtó. A 3.18 ábr egy egyszerő példát mutt erre. Az UML formlizmusokt és UML lpú tervezést itt bıvebben nem tárgyljuk, hiszen múlt féléves Beágyzott rendszerek szoftvertechnológiáj (VIMIM150) tárgyból ezzel részletesen fogllkoztk. Clss: Mesurement device Attrimutes: - Mesured vrible tbles - Sensors list - Clibrtion tbles Methods: - Mesure - Cllibrte - Send mesurements 1 1 Clss: Sensor Attrimutes: - Sensor limits - Sensor clibrtion prmeters - Sensor vlue Methods: - Mesure - Cllibrte - Power off 4 1 Clss: Comm-interfce Attrimutes: - Chnnel prmeters - Dt rte Methods: - Send dt - Receive Dt - Connect 3.18 ábr Egy mérıeszköz Clss digrm tervének részlete Scherer Blázs (scherer@mit.bme.hu), 2010.

46 Rendszertervezés (VIMM238) 46 Szoftver rétegek meghtározás A szoftver funkciókt legtöbb esetben rétegekre bontják. Ezek rétegek tipikusn hrdwre bstrction lyer, kernel / device drivers, ppliction support lyer és z ppliction lyer. A kommunikációs protokolloktól eltérıen szoftver rétegek áltlábn nem z ún. liner-order lyer model lpján épülnek fel, mint például z OSI rétegek, hnem z ún. strict-order lyered model lpján. A liner-order lyer model zt jelenti, hogy egy felsıbb réteg csk követlen ltt lévıvel kommunikálht, míg strict-order lyered model csk zt definiálj, hogy egy lcsonybb rétegbeli nem férhet hozzá mgsbb rétegbeli szolgálttásokhoz, de mgsbb rétegbeli elemek minden lcsonybb réteghez hozzáférhetnek. A szoftvertervezés egyik legfontosbb része ennek réteges szerkezető API (Appliction Progrming Interfce) hierrchiánk megteremtése. Egy jól létrehozott réteges szerkezet biztosítj kód könnyő hordozhtóságát, vlmint ngyfokú újrfelhsználhtóságát. Rossz struktúr grntáltn káoszhoz vezet. Egy ilyen ngyon egyszerő szoftver réteg hierrchi mitmót API is (3.19 ábr). Ennél jól láthtó, hogy z MCU-API-k áltl nyújtott közös felülettel oldhtó meg, hogy mind 32 bites ARM, mind 8 bites AVR pltformon mőködjenek kijelzı és rádió kezelıi függvényei. Alklmzás DPY-TRM API COM-R04 API Hrdwre független Softwre MCU-ARM API MCU API MCU-AVR API Hrdwre függı Softwre ARM AVR Hrdwre 3.19 ábr A mitmót API-k hierrchikus szerkezete Egy áltlános beágyzott rendszer szoftver rétegeinek bemuttásához jó péld z elızıekben már megismert ecos operációsrendszerrel összeintegrált mitmót pi (3.20 ábr). Az ábrán láthtó legtöbb beágyzott rendszerben lklmzott réteg megnevezési konvenció is. Scherer Blázs (scherer@mit.bme.hu), 2010.

47 Rendszertervezés (VIMM238) 47 Appliction Librries Hrdwre független mitmót API Felhsználói project ISO C Mth DPY-TRM COM-R04 MIKROP Kernel MCU-ARM API Hrdwre Abstrction Lyer interrupts Device Drivers Seril I/O kezelés SPI Elıre fordított ecos distribúció Exceptions I2C 3.20 ábr Egy áltlános beágyzott rendszer szoftverrétegei (Az ARM-es mitmót kárty operációs rendszerrel) A szoftver mőködési módok meghtározás Egy beágyzott rendszeren futó progrmnk áltlábn több mőködési módj vn. Ilyen módok tipikusn Bemérési mód - Klibrációs mód Szerviz mód Energitkrékos üzemmód megbízhtóságkritikus csökkentett üzemmód Inicilizációs mód Normál mőködés - Hibmód stb. Természetesen nem minden üzemmód létezik minden rendszernél. Például egy rádiós hálózti eszköznek áltlábn nincs megbízhtóságkritikus csökkentett módj. Egy utóipri vezérlınek nem feltétlenül vn energitkrékos módj (egyre többször vn), de mindig vn csökkentett (limp home) módj. Érdemes külön is kiemelni normál mőködés közben nem láthtó, ezért rutintln tervezı áltl sokszor kifelejtett mőködési módokt, mint például bemérési mód, szerviz mód stb. Ezek tipikusn rendszer terepre kihelyezését, gyártás ellenırzését könnyítik meg, kimrdásuk jelentısen csökkenti gyárthtóságot és hsználhtóságot is. A mőködési módok definiálás legtöbb esetben vlmilyen állpotgépes megdássl történik, hol mőködési módokon kívül mőködési módok közötti átjárhtóság feltételeit is megdjuk. Erre áltlábn UML Stte digrmmot hsználnk. Scherer Blázs (scherer@mit.bme.hu), 2010.

48 Rendszertervezés (VIMM238) 48 Inicilizációs mód Szerviz mód Hib mód Normál mőködés Klibráció Energitkrékos mód 3.21 ábr Egy beágyzott rendszer tipikus mőködési módji és zok kpcsolti Szoftver komponensek specifikálás A Szoftver komponensek specifikálás lépés ngol neve: Specifiction of softwre components. A szoftver rchitektúr megtervezésénél specifikálásr került, hogy rendszer milyen szoftver komponensekbıl áll, és hogy ezeket milyen interfészek kötik össze. Ennek lépésnek célj, hogy kidolgozz z egyes komponensek részletes viselkedését. Egy szoftver komponens specifikációját három részbıl: z dtmodellbıl, viselkedési modellbıl és rel-time modellbıl állítják össze. Softwre rchitektúr Teszt eredmények (A V modell másik ágából) Kpcsolt tesztelési ággl Szoftver komponens specifikálás Adtmodell specifikálás Viselkedési modell specifikálás Rel-time modell specifikálás Szoftver komponens specifikáció Teszt esetek (A tesztelés számár) Kpcsolt tesztelési ággl 3.22 ábr A szoftverkomponensek specifikációjánk folymt Scherer Blázs (scherer@mit.bme.hu), 2010.

49 Rendszertervezés (VIMM238) 49 Az dtmodell meghtározás A szoftver komponensek specifikációjánk elsı lépése z dtmodell megdás. Az dtmodell trtlmzz, hogy z dott komponensnek milyen bemenetei és kimenetei vnnk, és bemenetekbıl hogyn állítódik elı kimenet. Ennek elsı lépése, hogy elvontkozttunk z dtok tényleges hrdver implementációjától, és meghtározzuk, z dtok bsztrkt ábrázolásánk módját: Sklár értékek Vektorok, egydimenziós tömbök Mátrixok stb.. A következı lépés, z dtokon végzett mőveletek specifikációj. Erre sokszor lklmznk vlmilyen grfikus progrmozási nyelvet. Ilyen például z ASCET, Mtlb Simulink, LbVIEW stb (3.23 ábr). Erre többnyire zért vn szükség, mert ezek z dtmodellek legtöbb esetben vlmilyen szbályozástechniki részhez, vgy más, igen speciális ismereteket ún. domin specifikus tudást igénylı részhez kötıdnek. Ezekhez áltlábn speciális tudású, nem feltétlenül villmosmérnök fejlesztıket lklmznk, kik nem jártosk beágyzott rendszerek fejlesztésében, viszont Simulink, ASCET, stb. domin specifikus nyelvekben otthonosn mozognk. Tehát ezek domin expert-ek elkészítik és szimulálják funkciót (pl.: szbályozás) és zt után vgy egy progrmozó lekódolj, vgy utomtikus kódgenerátorokkl kódot generálnk belıle vezérlı számár. A félreértések elkerülése végett: áltlábn nem z egész rendszer szoftverét generálják, hnem nnk vlmilyen speciális tudást igénylı részét, és után zt integrálják össze többi, áltlábn kézzel írt kóddl (ez módszer egyre szélesebb körben kezd elterjedni) ábr Péld egy szbályozás dtfolym ábrázolásár Simulinkbn Az dt és viselkedési modellt és zok verzióit néhány esetben élesen szét is válsztják külön dt és vezérlı szoftver verziókt létrehozv. Ezt szétválsztást tipikusn csk zokr részekre lklmzzák, melyek kizárólg z dtok megváltozttásávl új rendszer verziót képesek létrehozni. Ilyen például egy szbályozási kör, hol PID szbályozás prmétereinek megváltozttásávl egészen eltérı vezérlések hozhtók létre ugynzzl progrmszerkezettel és hrdverrel (gykorlti péld egy motorvezérlı, hol motor teljesítményének és típusánk változásávl vezérlés dti módosulnk, de vezérlési folym és hrdver nem feltétlenül). Scherer Blázs (scherer@mit.bme.hu), 2010.

50 Rendszertervezés (VIMM238) 50 A viselkedési modell meghtározás Bár z dtfolym gráfok egyszerően ábrázolhtók, mégsem hordoznk mgukbn minden információt szoftver komponens viselkedésérıl. Például, z dtfolym nem írj le, hogy minek htásár hjtódnk végre z egyes feldolgozó lépések, illetve meddig trtnk zok. Az ilyen leírások tipikusn szoftver viselkedési folymához trtoznk (figyelem, LbVIEW például keveri kétféle megjelenítést, és Simulinkbn is vn rá mód, hogy z dtfolym megjelenítés mellé Stte flow-vl viselkedési leírást is létrehozzunk.) A vezérlési folym sokszor vlmilyen folymtábrávl, vgy struktrogrmml kerül leírásr. Ezeknek trtlmzni kell végrehjtás sorrendjét, z esetleges elágzásokt, z ismétléseket, iterációkt, illetve többi komponenssel vló kpcsolttrtást. A legelterjedtebb leírási mód z állpotgépes (FSM Finite Stte Mchine) leírás, legtöbbször z UML Stte digrm formátumábn, vgy hhoz hsonló módon megdv. Elsısorbn nnk köszönhetı z FSM lpú leírás elterjedése, hogy modern eszközökkel z így létrejött leírásból közvetlenül kód generálhtó. Így modellben formálisn verifikált mőködés egy bizonyítottn jól megírt kódgeneráló segítségével vlóságbn is helyes mőködést tud grntálni. Számtln ilyen állpot digrmból kódot generáló eszköz létezik picon, például IAR VISUAL Stte-je (3.24 ábr) ábr IAR Visul Stte-bıl létrehozott állpotgép. Az rel-time modell specifikálás A rel-time modell specifikálás rész fogllkozik zzl, hogy szoftverkomponens egyes funkcióit tszkokb rendezze. Illetve, hogy megszbj z így tszkokb rendezett vezérlések idılimitjeit, úgy hogy szoftverrendszer mjd teljesíteni tudj techniki rendszer rchitektúr áltl megszbott rel-time kritériumokt. Tehát z egyes szálkr szokásos prmétereket, mint végrehjtási idı (execution time), válszidı (response time), htáridı (dedline), ktivitási rát (ctivtion rte) kell megállpítni úgy, hogy együttesen betrtsák techniki rendszerterv rel-time kritériumit. Scherer Blázs (scherer@mit.bme.hu), 2010.

51 Rendszertervezés (VIMM238) 51 A tszkokr vló szétszedésnél z dtfolymot szokták feldrbolni legtöbb esetben. A tszkok létrehozásánál fokozottn figyelembe kell venni z lklmzni kívánt futttókörnyezet, rel-time operációs rendszer tuljdonságit. Preemptív mőködés esetén meg kell tudni htározni zt, hogy z egyes szálk hogyn és mennyire késleltetik egymást, és ezzel mennyire befolyásolják rendszer mőködését. Erre egy elterjedt és széles körben lklmzott módszer például Dedline Monotonic Anlysis (DMA). A DMA-t itt részletesen nem muttjuk be, mert z szerepelt múlt féléves: Vlós idejő és biztonságkritikus rendszerek (vimim151) tárgybn A szoftver komponensek implementálás Az implementálási folymt során z elızıekben megtervezett dt és viselkedési modellt vlósítják meg (3.25 ábr). Softwre komponens specifikáció Teszt eredmények (A V modell másik ágából) Kpcsolt tesztelési ággl Szoftver komponens specifikálás Adtmodell megvlósítás Viselkedési modell megvlósítás Rel-time modell megvlósítás megvlósított softwre, forrás kód Teszt esetek (A tesztelés számár) Kpcsolt tesztelési ággl 3.25 ábr A szoftver komponensek implementálás Hrdver limitációk A megvlósítási folymtnál z egyik fontos megkötést jelentek hrdver áltl szbott korlátok. A hrdver költség legtöbb iprágbn (például z utóiprbn) fontos kérdés. Lényeges, hogy kár csk pár centtel is, de olcsóbb legyen hrdver. Ezért sokszor plusz nehézség rkódik szoftverre, mert számos esetben inkább megnövelik szoftver fejlesztési költségeket, h spórolni tudnk hrdveren, mi ngyobb drbszámnál áltlábn meg is térül. Bár hrdver-szoftver szétválsztás korábbi techniki rendszer rchitektúr tervezésénél dılt el, de nnk htási itt is érzıdnek. Például költségek kímélése mitt szbályozási körben lklmzott processzorok nem lebegıpontosk, hnem fix pontosk. Az ilyen fontos megkötések pedig rányomják bélyegüket z egész progrmr, hiszen például z dott esetben fokozott figyelmet kell fordítni számábrázolás mitti kerekítési, lulcsordulási hibákr, mi mitt rossz esetben kár z egész szbályozási kör is instbillá válht. Szintén fontos megkötést jelenthetnek ROM és RAM területek korláti. Egy szokásos mikrovezérlıben jóvl több ROM terület tlálhtó, mint RAM. Emitt, illetve mitt, hogy ne kelljen ngyobb memóriájú mikrovezérlı vriánst venni, progrmozóknk, hol lehetıség Scherer Blázs (scherer@mit.bme.hu), 2010.

52 Rendszertervezés (VIMM238) 52 vn rá, spórolni kell RAM területtel és inkább ROM-ot hsználni. (Például: néh bonyolult sok változót igénylı számítások helyett look-up tble-t hsználnk fel) Természetesen ezek z optimlizációs lépések nem mehetnek minıség és megbízhtóság rovásár. Az dtmodell implementációj Az dtmodell megvlósításánál már megtervezett változókt implementáljuk. Itt legfontosbb lépés tervezés és z implementáció közötti különbségek kezelése. Például mikor egy vezérlı külsı és belsı RAM-ml is rendelkezik z sem mindegy, hogy mely változókt rkjuk belsı RAM területre (gyorsbb elérés) és melyeket külsı RAM-b. Ennél lépésnél szokták pontosítni változók nyers értéke és fiziki világ közötti viszonyt is. Például, h egy hımérséklet értéket egy 16 bites változóbn tárolunk egész számokként 100-d fokos felbontássl, kkor itt djuk meg és dokumentáljuk ezt kódolási formát (specifikáljuk z ofszetet és fktort). Ezeket z dtokt néhány helyen külön leíró file-b rögzítik, és fontos szerepet kpnk tesztelési szkszbn (ilyen terület például z utóipr, hol dignosztiki és klibrációs protokollok hsználják ezeket leíró file-okt tesztelési, bemérési lépéseknél). A fiziki megvlósítás során további limitációk dódhtnk különbözı ritmetiki és számítási módok mitt. Ilyen hibforrást jelenthetnek kerekítési hibák. Ahogyn már szó volt ról, ezek tipikusn z lklmzott mikrokontroller korlátiból dódnk. Az ún. pproximációs hib z lklmzott számítási eljárásokból dódik (például egy nemlineritás ideális, hrmdfokú kompenzációj helyett csk másodfokú kompenzációt lklmzunk) Ezeket problémás részeket fel kell tárni, és meg kell vizsgálni, hogy okozhtnk e mőködésbeli hibát. A viselkedési leírás implementációj A viselkedési modell implementációj specifikációt hivtott kiegészíteni z dott processzor, hrdver korlátit figyelembe véve, bár ezeket sokszor nehéz pontosn megdni. A rel-time modell implementálás Ennél résznél rel-time modell specifikációjánk betrtásához z implementáció elıtt pontosn meg kell vizsgálni z dott hrdver tuljdonságit, például interrupt modelljét, interrupt ltency-ét stb. Az dott vezérlı ismeretén túl ngyon fontos z operációs rendszer dott vezérlın vló mőködésének feltérképezése is. Bár Rel Time operációs rendszerek esetében legtöbbször elmondhtó, hogy egy operációs rendszer szolgálttás végrehjtásánk viszonylg stbil idıszelete vn ( minimális és mximális idı közel megegyezik) ezeket, z idıket zonbn minden rchitektúrár külön mérésekkel ellenırizni kell. További fontos lépés még z operációs rendszer felkonfigurálás is. A beágyzott operációs rendszerek némelyikénél például lehetıségünk vn z ütemezési lgoritmus, vgy prioritás inverzió elkerülésére lklmzott protokoll megdásár is. Ezek helytelen beállítás könnyen okozht nem várt mőködési rendellenességet A megfelelı implementációs környezet kiválsztás A legtöbb cégnél megvlósítási lépéseket igen szoros szbályokhoz kötik, melyek természetesen függnek ttól, hogy z dott megvlósítndó komponens megbízhtóságkritikus modul része-e, vgy nem (3.26 ábr). Ezeknek szbályoknk z lpjivl célszerő bıvebben megismerkedni, mert szinte minden cégnél lklmznk ilyeneket. Scherer Blázs (scherer@mit.bme.hu), 2010.

53 Rendszertervezés (VIMM238) 53 Szbály SIL0 SIL1 SIL2 SIL3 Megfelelı progrmozási nyelv hsznált Coding style guide hsznált Elnevezési konvenció hsznált A nyelvi készlet korlátozás Deffenziv progrmozás Dinmikus memórikezelés kerülése Interuptok korlátozott hsznált Pointerek korlátozott hsznált Jelmgyrázt: "-": tilos "0": nem szükséges "+": jánlott "++": kötelezı 3.26 ábr Mint z implementációs szbályokr SIL réteg függvényében. A zölddel kijelölt megkötésekrıl, mint dinmikus változók kerülése, pointerek korlátozott hsznált stb. már sokt hllhttunk. Ami érdekesebb z nrncssárg csoport, mi hogy láthtjuk megbízhtóságossági szinttıl függetlenül kötelezı, de kevesebb szó esett errıl területrıl z eddigi tnulmányok során. Ebben fejezetben ezeket szbályokt vesszük át részletesebben. Megfelelı progrmozási nyelv hsznált A beágyzott rendszereknél mi npig C progrmozási nyelv legelterjedtebb, és várhtón még egy jó drbig ez így is lesz. Ezt támsztj lá z Embedded Mrket Study 2009 felmérés eredménye is (3.27. ábr). Bár zt gondolhtnánk, hogy ezek után elég zt mondnunk, hogy C-t kell hsználni. Figyelembe kell zonbn venni, hogy C-nek is több kicsit eltérı változt létezik, és z egyes fordítók sem teljesen egyértelmően kezelik ezeket különbségeket. Tehát nyelv kiválsztásán túl legtöbb cégnél pontosn rögzítik nyelv verzióját is (például ISO/IEC 9899:1999), és ellenırzik fordítók dott verzióvl vló komptibilitását is. Scherer Blázs (scherer@mit.bme.hu), 2010.

54 Rendszertervezés (VIMM238) ábr Az Embedded mrket study 2009 felmérése beágyzott rendszeres fejlesztéseknél hsznált progrmozási nyelvekrıl Coding style guide és elnevezési szbályok hsznált A fejlesztés során legtöbb cégnél hsználnk ún. Coding, vgy Progrmming Style Guideokt. Ezek többnyire cég specifikusk. Az interneten számos ilyen Style Guide-ot tlálhtunk. Ezek következı területeket fedik le: (Mindegyik területhez egy-egy mintát is muttunk, de trtsuk szeme elıtt, hogy ez ngyon szervezet-, cégfüggı.) File struktúr és file elnevezési konvenció A file nevének krkterrel kell kezdıdnie. A file neve nem lehet 8 krkternél hosszbb, kiterjesztése pedig 3 krkternél hosszbb. A szokványos file típus neveket kell hsználni:.c,.sm/.s,.o,.bin,.hex etc. Progrm file-ok szerkezete A progrm file szerkezete következı: 1, Komment file nevérıl, rendeltetésérıl, szerzıjérıl, verziójáról, és verzió history-árol. Egyes verziókövetı rendszerek utomtikusn generálják, módosítják file verziór vontkozó kommenteket. Ilyenkor ezeket fejlesztınek áltlábn tilos kézzel módosítni. 2, Heder file include-ok 3, Definiciók következı sorrendben: Típus definíciók, Define-ok, Konstns mkrók függvény mkrók, 4, Globális változók: extern, nem sttic, sttic globl sorrendben 5, függvények: áltlábn hívási sorrendben, h egy mód vn rá. Heder file-ok szerkezete 1, Komment file nevérıl rendeltetésérıl, szerzıjérıl, verziójáról, és verzió historyárol. A file neve sohsem lehet normál C inklúdnévvel egyezı pl.: mth.h. Scherer Blázs (scherer@mit.bme.hu), 2010.

55 Rendszertervezés (VIMM238) 55 2, A következı file kezdési szerkezet kötelezı: #ifndef EXAMPLE_H #define EXAMPLE_H... /* body of exmple.h file */ #endif /* EXAMPLE_H * 3, Fejléc file-okbn ne deifiniáljunk változókt h egy mód vn rá. A kommentek szerkezete Minden cégnél lklmznk kommentezési stílus szbályokt. Ngyon sok helyen hsználják gykorlton is bemuttott Doxygen kommentbıl dokumentációt generáló progrmot és nnk kommentezési stílusát. Fontos megjegyezni, hogy szinte mindenhol z ngol nyelvő kommentezést és változó elnevezést követelik meg, nem engedélyeznek más nyelvet. Deklrációs és elnevezési szbályok Ezeket áltlábn külön leírt szbályok dják meg, ilyen például z egyik leghíresebb z ún. Hungrin Nottinon, melyet Simonyi Károly vezetett be Microsoftnál. Az elnevezési szisztém mgyr elnevezési logikából indul ki, hol vezetéknév megelızi z dott keresztnevet. Ezt próbálj változókr is bevezetni, hol elıször típus, vgy lklmzási kör szerepel és után csk z dott név. Áltlábn kétfjt konvenciót különböztetnek meg System-et és z Appliction-t, System esetében változó típus, z Appliction esetében z lklmzás típus vn belekódolv változó nevébe. Néhány péld: bbusy : boolen capples : count of items dwlightyers : double word (system) fbusy : boolen (flg) nsize : integer (system) vgy count (ppliction) isize : integer (system) vgy index (ppliction) fpprice: floting-point dbpi : double (system) pfoo : pointer rgstudents : rry, vgy rnge szlstnme : zero-terminted string u32identifier : unsigned 32-bit integer (system) sttime : clock time structure fnfunction : function nme Ez jelölésrendszer sokszor kiegészül láthtóságot befolyásoló elıtgokkl is: g_nwheels : member of globl nmespce, integer m_nwheels : member of structure/clss, integer m_wheels : member of structure/clss s_wheels : sttic member of clss _wheels : locl vrible Scherer Blázs (scherer@mit.bme.hu), 2010.

56 Rendszertervezés (VIMM238) 56 A Hungrin nottion mellett és ellen is szólnk érvek, lévén gykorltilg redundáns információt trtlmz, de z kétségtelen, hogy formlizálj változó elnevezést, és már önmgábn emitt sok helyen hsználják. A nyelvi készlet korlátozás Még szbványos ISO C változtok specifikálás is igen szbtos. Rengeteg szintktilg helyes, de szemntikilg rossz megoldást lehet létrehozni, mely olyn iprágkbn, hol vlmennyire is megbízhtóságkritikus z lklmzás, nem megengedett. Ahhoz, hogy elkerülhessük ezeket szintktikilg helyes, de szemntikilg veszélyes részeket, C nyelvi készletét korlátoznunk kell. Jelenleg két ilyen nyelvi korlátozás terjedt el. A MISRA-C, és CERT Secure C szbálycsomgj. MISRA C (Motor Industry Softwre Relibility Assocition) Az elsı MISRA C szbályverziót 1998-bn hozták létre. Célj z volt, hogy jvíts z UK (United Kingdom) utóiprábn hsznált szoftverek minıségét. A MISRA-C 1998 sikere nem csk z utóiprr terjedt ki, hnem széles körben lklmzásr került repülıgépiprbn vlmit z egészségügyi iprbn is. A MISRA-C 2004 szbvány jelenlegi verziój, mely elfogdásr került z USA-bn (SAE J2632) és Jpánbn is. A MISRA-C 2004 jvítj MISRA-1998 hibáit, és pontosítj zt. A szbvány 121 Mndtory (kötelezı) és 20 Advisory (jvsolt) szbályt trtlmz C nyelv leszőkítésére. A MISRA C röviden összefogllv következı célokt tőzte ki: Szintktikilg helyes, szemntikilg rossz megoldásokr felhívni figyelmet. Tiltni nem egyértelmő változó típus hsználtot. Szbályozni precedenci zárójelezéseket. Tiltni nem strukturált progrmozást eredményezı szerkezeteket. A MISRA közösség C-n kívül még C++ progrmozási nyelvhez is kidolgozott szbályrendszert. CERT C Secure Coding Stndrd A CERT: Crnegie Mellon University Softwre Engieenring Institute, mely tgj SEI-nek (Softwre Engieenering Institute). Az intézet áltl kidolgozott Secure coding szbványok következı nyelvekhez jöttek létre: C, C++, JAVA. A Cert Secure C prioritási osztályokb sorolj szbályit. Az osztályokt három lp szempont szerint htározzák meg: Severity: A szbály be nem trtás áltl kiváltott hib kár mértéke. Low (lcsony) Medium (közepes) High (mgs) Likehood: Mekkor vlószínősége, hogy szbály be nem trtás esetén hib jelentkezik. Unlikely (vlószínőtlen) Probble (lehetséges) Likely (vlószínő) Remedition cost: Milyen költséges hogy szbályt betrtsuk. Scherer Blázs (scherer@mit.bme.hu), 2010.

57 Rendszertervezés (VIMM238) 57 High (mnul detection nd correction) Medium (utomtic detection, mnul correction) Low (utomtic detection nd correction) A prioritási osztályokt ezeknek ktegóriáknk vizsgáltávl három szintbe sorolták Level1, Level2, Level3-b (3.28 ábr). Level 1: Priorítás Ngy kárt okozó, vlószínő és viszonylg olcsón jvíthtó hibák Level 2: Priorítás 6-9 Level 3: Priorítás 1-4 Közepes kárt okozó, közepes vlószínőségő, és közepes jvítási költcségő hibák Nehezen jvíthtó kis vlószínőségő és kis kárú hibák 3.28 ábr A CERT Secure C priorítási és szintek közötti összefüggések A CERT C szbályok z Interneten szbdon hozzáférhetıek, Mindegyik szbálynál mellékelik nnk prioritását is. 01. Preprocessor (PRE) 02. Declrtions nd Initiliztion (DCL) 03. Expressions (EXP) 04. Integers (INT) 05. Floting Point (FLP) 06. Arrys (ARR) 07. Chrcters nd Strings (STR) 08. Memory Mngement (MEM) 3.3. A V-modell tesztelési ág Ez fejezet V-modell tesztelési ágánk z áttekintését szolgálj. A fejezet szándékosn rövid és áttekintı jellegő, mert ezzel témterülettel Mjzik István Vlós idejő és biztonságkritikus rendszerek tárgybn már részletesen fogllkozott. Scherer Blázs (scherer@mit.bme.hu), 2010.

58 Rendszertervezés (VIMM238) 58 Az egyes V-modell szerint végrehjtott tesztelési lépések elıtt 3.29 ábr egy gyors áttekintést d különbözı szoftvertesztelési módszerekrıl és zok lklmzási pontjáról z életciklus modellben. Feketedoboz (Blckbox) tesztek Rndom tesztek Felhsználói funkcionlitás tesztek Stressz tesztek Rendszer tesztek Szürkedoboz (Greybox) tesztek Limit érték ellenırzések Equivlence clss módszerek Alrendszer és integrációs tesztek A specifikált funkcionlitáson lpuló Fehérdoboz (Whitebox) tesztek Sttikus nlízis Kódfedettség vizsgáltok Modul tesztek Progrm struktúrán lpuló 3.29 ábr A tesztelési módszerek áttekintése Az egyes V-modell lépéseknél gykorltilg ezeket módszereket fogjuk picit részletesebben áttekinteni Szoftverkomponensek tesztelése A szoftverkomponensek tesztelése tipikusn fehérdoboz módszerekkel történik. Ilyen módszer például sttikus kódnlízis z dtmodell ellenırzésénél, vezérlési gráf ellenırzése viselkedési modellnél. Kpcsolt tervezési ággl Az implementáció teszt eredményei A specifikáció teszt eredményei Tesztelt szoftver komponens Szoftver komponens tesztelése Adtmodell ellenırzés Viselkedési modell ellenırzés Rel-time modell ellenırzés Kpcsolt tervezési ággl Teszt esetek z implementáció lépéstıl Teszt esetek z specifikáció lépéstıl megvlósított szoftver, forrás kód 3.30 ábr Szoftverkomponens tesztelése Scherer Blázs (scherer@mit.bme.hu), 2010.

59 Rendszertervezés (VIMM238) 59 Adtmodell ellenırzés A szoftver komponensek tesztelésénél z elsı lépés z dtmodell ellenırzése. Ez lépés mgábn hordozz tervezés során specifikált, szoftverkomponens áltl végrehjtott dtfolym helyességének ellenırzését, vlmint komponens interfészeihez trtozó limit értékek és zok átlépésének tesztelését. Tlán ennél érdekesebb z implementációt és nem specifikációt ellenırzı sttikus nlízis rész. A sttikus nlízis kód futttás nélküli kódelemzıvel történı ellenırzését jelenti és elsısorbn z úgynevezett runtime, vgy futási hibák felderítésére szolgál. Runtime hibánk nevezünk minden lább felsorolt progrm futás közben bekövetkezı hibát: Aritmetiki hibák: overflow, underflow, divide by zero Pointer ritmetiki hibák Tömbtúlindexelések Függvény prméter problémák Az összes ngyobb cégnél szbály, hogy ezeknek futási idejő hibáknk kivédéséhez vlmilyen eljárást kell lklmzni. A MISRA-C z lábbi szbályt hozt ezzel kpcsoltbn: A Run-time hibák minimlizálásár minimum egyet z lábbi eljárások közül hsználni kell. o Sttikus kód nlizátor o Dinmikus kód nlizátor o Explicit lekódolás run-time hibák kezelésének A cégek áltlábn sttikus kódnlizátort szoktk hsználni. A 3.32 ábr bemuttj, hogy ezt z nlízist függetlenül megkívánt megbízhtóságtól végrehjtják. Tevékenység SIL0 SIL1 SIL2 SIL3 Kódig guidleine-nk vló megfelelıség ellenırzése Sttikus kódnlízis Jelmgyrázt: "-": tilos "0": nem szükséges "+": jánlott "++": kötelezı 3.32 ábr Sttikus kódnlízis szükségessége SIL réteg függvényében Egy ilyen széles körben elterjed sttikus kódnlizátor például Polyspce. A Polyspce MthWorks cég terméke és C/C++ vlmint Ad nyelvhez nyújt sttikus kódnlízis szolgálttást. Beágyzott rendszerek esetében külön kedvelt z funkciój, hogy MISRA-C szbályok ellenırzésére is képes. A Polyspce z áltl ellenırzött kódrészletben z egyes változókt különbözı színkódokkl látj el nnk függvényében, hogy zok hordoznk-e vlmilyen potenciális veszélyt (3.33. ábr). Scherer Blázs (scherer@mit.bme.hu), 2010.

60 Rendszertervezés (VIMM238) 60 A színkódok jelentése következı: 3.33 ábr Polyspce elemzés Zöld: bizonyítottn helyes minden körülmények között Piros: bizonyítottn rossz minden körülmények között Szürke: bizonyítottn elérhetetlen kód Nrncs: bizonyos körülmények között lehet rossz A változók ilyen sttikus elemzése úgy vlósul meg, hogy Polyspce progrm összes változójánk lehetséges értékeit egy bsztrkt interpretációnk nevezett módszer segítségével követi. A Polyspce következı hibákt képes sttikus nlízissel felderíteni: Osztott váltózók kezelése (multi tszkból dódó problémák) Tömbindexelési hibák detektálás Hibás pointer hivtkozások Inicilizáltln változó olvsás Hibához vezetı ritmetiki eljárások (nullávl vló osztás, gyökvonás negtív számból) Flot vgy Integer változók lul, felülcsordulás Illegális típuskonverziók Elérhetetlen kód Végtelen ciklusok Polyspce MISRA-C megfelelıséget 102 szbályr teljesen 20 szbályr részletesen képes ellenırizni (A MISRA szbályok egy jó része környezetre vontkozik, melyek nem Scherer Blázs (scherer@mit.bme.hu), 2010.

61 Rendszertervezés (VIMM238) 61 ellenırizhetıek egy ilyen nlízis során). Az MISRA szbályok ellenırzését egyesével be lehet engedélyezni, vgy tiltni progrmbn. A Polyspce, mint z összes sttikus elemzı igen költséges progrm, így gykorltok során nem volt lklom bemuttni. Ugynkkor érdemes megjegyezni, hogy egy másik sttikus nlizátornk Gimpel-nek létezik egy tesztoldl, hov rövid kódrészleteket lehet beilleszteni ellenırzésre ezzel demonstrálv tool képességeit. Ezt z oldlt érdemes lehet felkeresni: A viselkedési modell ellenırzése: Kódfedési vizsgáltok A viselkedési modell ellenırzése során leggykrbbn lklmzott tesztek z ún. kódfedettség vizsgáltok, hol zt ellenırizik tesztelık, hogy progrm minden sor, feltétele, ág stb. végrehjtásr kerül-e (természetesen úgy, hogy végrehjtás eredménye helyes). A kódfedési vizsgáltokt z ún. vezérlési gráf lpján létrehozott tesztekkel szokták végezni. A tesztelési irodlom következı fedési vizsgáltokt ismeri [Mjzik István]: Utsítások lefedése: Minél több utsítást végrehjtni Döntési ágk lefedése: Elágzások esetén minden iránybn továbbmenni Feltételek lefedése: Feltételes elágzásokbn minél több feltétel kombinációt kipróbálni Utk lefedése: Minél több független utt bejárni gráfbn 3.34 ábr Péld egy kódrészlethez trtozó vezérlési gráfr A különbözı fedettségi vizsgáltok kicsit részletesebben: Utsítás lefedettség: Tesztelés során végrehjtott utsítások szám / Összes utsítás szám Nem szigorú: Utsítások kihgyási feltételeit nem veszi figyelembe pl. k0; if (>0) k1; m1/k; lefedése esetén z 0 eset vizsgált kimrd Döntési ág lefedettség: Tesztelés során végrehjtott döntési ágk szám / Összes lehetséges döntési ág szám Scherer Blázs (scherer@mit.bme.hu), 2010.

62 Rendszertervezés (VIMM238) 62 Nem szigorú: if (>0 && (sfe(c) sfe(b)) strt(); stop(); A fordító optimlizálás mitt sfe(b) hívás be sem következik, h sfe(c) igz. Feltétel lefedettség: Feltételekben tesztelt bemeneti kombinációk szám / Feltételek összes bemeneti kombinációink szám Aránylg bonyolult tesztelés sok lehetséges kombináció beállítás mitt. Út lefedettség: Bejárt független utk szám Összes független út szám Független utk: vn olyn pont vgy él, mi egy másik útbn nincs meg Jellemzés: A gráf ciklomtikus komplexitás (CK): A független utk mximális szám. CK(G)E-N+2, hol E: élek szám, N: pontok szám G vezérlési gráfbn 100% út lefedettség együtt jár: 100% utsítás lefedettség 100% ág lefedettség A kódfedettségi vizsgáltok elvégzésére lpvetıen két lehetıségünk vn. Az egyik lehetıség egy pusztán szoftveres mérés kód felmőszerezésével. Ez megoldás memóri és végrehjtási idı overhed-et jelent és tesztelés után tipikusn nem szedhetı ki mőszerezés, mert z megváltozttná rel-time viselkedést. Ilyen szoftveres kódfedést mérı eszköz például GCC toolchinhez trtozó GCOV, mi elvégzi kód felmőszerezését és futttás ltt készít egy logfile-t, mibıl meg tudj htározni, hogy z egyes sorok hányszor futottk le. Bár GCOV lpvetıen nem beágyzott rendszerekre tervezett (logfile-okt hoz létre), de kis átlkítássl zoknál is hsználhtó. #include <stdio.h> int min (void) { 1 int i; 10 for (i 1; i < 10; i++) { 9 if (i % 3 0) 3 printf ("%d is divisible by 3\n", i); 9 if (i % 11 0) ###### printf ("%d is divisible by 11\n", i); 9 } 1 return 0; 1 } 3.35 ábr Péld GCOV eredményekre: bl oldlt láthtó szám muttj, hogy hányszor futott le z dott kódsor. Scherer Blázs (scherer@mit.bme.hu), 2010.

63 Rendszertervezés (VIMM238) 63 A kódfedettségi vizsgáltok elvégzésének másik, htékonybb módj hrdwre-es trce lklmzás, hiszen ezek nem befolyásolják z dott rendszer mőködését. A hrwre-es megfigyelésre lpvetıen két lehetıségünk vn. Az egyik lehetıség cím és/vgy dtvonl figyelése, mi igen komplex hrdwre támogtást igényel így drág, további problém ennél módszernél, hogy legtöbb modern mikrovezérlı integrált progrm és dtmemóriávl rendelkezik, így nem lehet hozzáférni cím és dtvezetékeikhez. A másik gykorltbn jobbn lklmzott megoldás beágyzott trce modulok hsznált. A legtöbb modern mikrovezérlınél ugynis mgáb mgb integrálnk olyn trce blokkokt, melyek z ilyen jellegő rel-time megfigyelést lehetıvé teszik. Ilyen trce blokk például z ARM mgoknál z Embedded Trce mcrocell. Ezekre hrdwre-es támogtásokr épülve komoly és drág eszközökkel, mint Luterbch trce kit-jei kódfedési vizsgáltok és rel-time viselkedést ellenırzı tesztrendszereket lehet felépíteni ábr Hrdwre-esen támogtott kódfedettség mérés: Luterbch trce eszközök A kódfedettségi vizsgáltokkl kpcsoltbn érdemes megjegyezni, hogy még profi toolokkl és képzett cspttl is igen idıigényes dolog. Ezért bonyolultbb fedési vizsgáltokt még ngy megbízhtóságú rendszereknél sem írják elı kötelezı érvényőre (3.36 ábr). Tevékenység SIL0 SIL1 SIL2 SIL3 Utsítás fedésvizsgált Döntési ág fedésvizsgált Feltétel lefedési vizsgált Utk fedési vizsgált Jelmgyrázt: "-": tilos "0": nem szükséges "+": jánlott "++": kötelezı 3.36 ábr Ajánlás kódfedési vizsgáltok elvégzéséhez A rel-time modell ellenırzése A rel-time modell ellenırzésénél z egyes szoftver részek tényleges futási idejét szokták lemérni. Ez jó pár esetben történhet trce toolok segítségével. Ami itt, és egy lépéssel késıbb szoftver rendszer integrálásánál pluszt szokott jelenteni z z RTOS nyomon követése és felmőszerezése. A legtöbb beágyzott operációs rendszer ugynis rendelkezik Scherer Blázs (scherer@mit.bme.hu), 2010.