Kutatói hallgató-ösztöndíj programomat illetve ezzel együtt két hónapos szakmai gyakorlatom a B.Braun Medical Kft. Fejlesztési osztályán végeztem 2013.07.01 és 2013.08.30 között. Két hónapos gyakornoki munkám alatt megismertem egy fejlesztési osztály működését, bekapcsolódtam a fejlesztői csoport munkájába, illetve megismertem a szoftver fejlesztői feladatok megoldási módszereit, metódusait. A B.Braun Medical Kft. orvosi eszközök gyártásával, forgalmazásával és orvosi szoftverek fejlesztésével foglalkozik. Munkám során a Dialog+ dialízisgép Top Level Control (TLC) alkalmazásának fejlesztésével foglalkoztam. A TLC alkalmazás felelős a rendszer kezelhetőségéért, többek közt a kommunikációval is a Low Level Control (LLC) programmal. A TLC kezelőfelület egy érintőképernyő segítségével tesztelhető a célgépen (Target System), illetve a fejlesztők számára rendelkezésre áll egy PC szintű fejlesztési lehetőség Linux rendszerkörnyezetben. Ez esetben az alkalmazás úgynevezett demo környezetben futtatható és tesztelhető. Ennek célja a fejlesztés gyorsítása, hogy ne kelljen folyamatosan a célgépeken tesztelni minden egyes változtatást, viszont sok esetben nem lehet kikerülni, hogy laborkörülmények közt, célgépen legyen az alkalmazás letesztelve.
A fejlesztés maga egy C programnyelven megírt programrendszer vizsgálatát jelenti, mely különböző feladatokra (tasks) van osztva. A feladatok különböző funkciókért felelnek mint például a felhasználói interface, LLC kommunikáció vagy alarm üzenetek kezelése. Minden taskhoz tartozik külön egy úgynevezett make file, mely az adott taskhoz futtatja le csak a C compilert (fordítót). A fejlesztés menete első lépésben a legújabb programverzió lekérdezése, a frissített fájlok lekérdezése a szerverről, majd összefűzése a lokálisan található fájlokkal. A szerver maga egy SVN (subversion) alapú repository rendszer, mely minden fejlesztő számára hozzáférhető és módosítható. A módosítás során a változtatott fájlokat kell „commit-álni”, majd ezután új verziót generálni, hogy áttekinthető legyen a fejlesztés menete. A fejlesztés fontos lépése továbbá hogy commit után egy fordítóprogram kiszűrje az esetleges hibákat illetve figyelmeztetéseket. Ez a program a QA C Source Analyser, mely egy kereskedelemben kapható szoftver, amely a MISRA-C:2004-es szabványrendszer szerint végez statikus kód analízist a forráskódon. Feladatom, a fordító által generált figyelmeztetések (warnings) számának csökkentése volt, olyan módon hogy a működő kód ugyanúgy fusson le, mint eredetileg. Statikus kódanalízisem során továbbá ügyelnem kellett, hogy új warningok/errorok ne keletkezzenek, ezért a változtatások után többször fordítottam le az adott forráskódot. Több esetben a változtatások befolyásoltak más forrásokban megadott kódrészleteket, ekkor közvetve ugyan de az adott feladat analízisébe más taskokból vett forrásfájlokat is át kellett írni, főleg header file-ok esetén volt erre szükség. A MISRA-C:2004-es szabványrendszer az ISO:C90 hivatalos C kódrendszer szabvány alapján készült. A szabványrendszer betartása, és eszerinti fejlesztés fontos, mivel a szabvány által kiszűrt warningok nélkül a programkódunk átláthatóbb és hordozható is lesz. Egy adott task kódanalízise után mentorom segítségével újra átnéztük a változtatásokat, illetve kérdéses esetekben konzultációt kértem egy adott warninghoz, majd a PC-n lévő demoprogramon megvizsgáltuk, hogy a változások hatására ugyanúgy működik-e. Felvetődött a generált bitfájt (ELF) vizsgálata is, hogy mindenképp biztos legyen a programkód konzisztenciája, mivel ekkor a kódanalízis gyorsasága mindenképp felgyorsult volna, időhiány miatt erre a feladatra nem került sor a szakmai gyakorlat során.
Kozma Dávid