Mechanical engineering | Studies, essays, thesises » Iteratív fejlesztés a műszeriparban

Iteratív fejlesztés a műszeriparban Bár jó „projektvezetők” az ókorban is voltak, ipari méretekben a múlt század közepe óta használják tudatosan a fenti módszertant. Számtalan megvalósítási módszere létezik (vízesés-modell, „V”-modell), melyek ugyan bizonyos részfolyamatokban (pld. tesztelés szerepe) különböznek egymástól, azonban valamennyi módszere lényege a fenti események egymásutánisága: párhuzamosan zajló tevékenységek kizárólag a „végrehajtás” fázisában történnek. A projektvezető folyamatosan nyomon követi az egyes feladatok alakulását, beavatkozási lehetősége mégis csekély: csak a rendelkezésre erőforrások (szakemberek, berendezések) körén bővíthet. Ez azonban egyrészt nemkívánatos költségnövekedéssel jár, másrészt legtöbbször a kívánt eredményt sem hozza meg, hiszen magához a bővítéshez is idő szükséges (betanítás, berendezés vásárlás). Mivel a tervezés során kizárólag

a projektindítás által meghatározott információk állnak rendelkezésre, ezért egyrészt a termékspecifikációnak minden részletre kiterjedőnek kell lennie, másrészt pedig ezek vagy a peremfeltételek bármilyen megváltozása a projekt sikertelenségét (időbeli vagy költségbeli csúszását) hordozza magában. Ugyanakkor a projekt során közvetlen kézzel fogható valódi eredmény csak a „lezárás” fázisban születik, így a megrendelő vagy a felső vezetés szemszögéből az előrehaladás nem követhető. „Agile” és „Scrum” módszerek A modern műszertechnika három nagyon különböző korú és sajátosságú műszaki tudományág eredményeit használja: mechanika, elektronika és szoftvertechnika. Míg a mechanika kézzel foghatót tervez, és a működési elve is többnyire látványos, addig az elektronikában a működés elve kevésbé látszik, így a hibakeresés sem magától értetődő. A szoftverírás során pedig egy absztrakt,

virtuális rendszer jön létre, ahol maga a produktum sem kézzel fogható! Ráadásul a szoftverfejlesztés mindössze alig 30 éves múltra tekint vissza, szemben az elektronika százéves és a mechanika több évszázados történelmével. Mivel az alkalmazott mechanika (a kvantummechanika és relativitáselmélet kivételével) az elmúlt száz év során lényegében nem változott, ezért a tervezési módszerek is ebben a témakörben a leginkább letisztultak. Hasonlóan igaz ez a projektvezetés módszertanára is. Azonban ezek a koordinációs, vezetési módszerek a műszertechnikában a három tudományág említett különbözősége miatt általában nem vagy csak korlátozottan alkalmazhatók. A különbséget elsősorban a legfiatalabb és legkevésbé kézzelfogható alkotóelem, a szoftver okozza. Klasszikus projektvezetési technikák és azok korlátai a modern műszerfejlesztésben A projektvezetés célja az függetlenül iparágtól vagy mérettől, hogy a

feladatok és a rendelkezésre álló erőforrások tervezésével és szervezésével a projektcélok az adott peremfeltételek mellett elérhető legoptimálisabban valósuljanak meg. A projektvezetés legegyszerűbb mérőszáma a „siker”, lezajlása pedig a következő 5 szakaszra bontható: 1. Indítás: A feladatok, célok és peremfeltételek rögzítése 2. Projekttervezés: A feladatok részfeladatokra bontása, a csapat és a nem személyi erőforrások meghatározása, határidők és mérföldkövek rögzítése. 3. Végrehajtás: Az egyes feladatokban leírt tevékenységek elvégzése. Lényegében ez a klasszikus értelemben vett fejlesztési munka. 4. Megfigyelés és beavatkozás: Átcsoportosítás vagy bármilyen egyéb beavatkozás, ha a végrehajtás nem a tervezésnek megfelelően történik 5. Lezárás: A termék bemutatása, a projekt értékelése 20 Iteratív fejlesztés a műszeriparban A végső siker tehát azon múlik, hogy a tervezéskor

megfelelő információ és tapasztalat áll-e rendelkezésünkre, amivel az egyes részfeladatok súlyát, idejét és erőforrásigényét becsülni tudjuk. Ezért gördülékenyebbek a mechanikai projektek az elektronikai és még inkább a szoftveres projektekkel szemben. Ha klasszikus projektvezetési technikát alkalmazunk mikrokontroller vezérlésű elektromechanikai rendszerek fejlesztésénél, akkor számolnunk kell azzal, hogy a projekt előrehaladása során a határidők folyamatosan elcsúsznak vagy az eredetileg becsült létszámnál jóval nagyobb létszámra lesz szükségünk. Erőforrásokban bővelkedő, jellemzően mechanikai múlttal rendelkező iparágakban (gépgyártás, autóipar) ez elfogadható, a modern műszeripari fejlesztések számára azonban ez az út járhatatlan! 2001. február 13: Kiáltvány az agilis szoftverfejlesztésért Egy közös téli vakáció alkalmával, agilis a Sziklás Hegység egyik leghíre- életrevaló, serény, sebb

lesiklópályája, a Snowbird tevékeny, mozgémellett készítette el 17 neves szoft- kony, ügyes, verfejlesztő, rendszertervező és in- hatékony formatikai projektvezető a modern forrás: idegen szoftverfejlesztést és projektvezetést szavak gyűjteménye megalapozó Agile Manifesto-t. Mint minden kiáltvány, ez is tömörségében szélsőséges és forradalmi, változást sürget és egyben elgondolkodtat. Mi a jobb szoftverfejlesztés módjait fedezzük fel azáltal, hogy fejlesztünk és segítünk másokat fejleszteni. Ezen munkában értékesebbnek tartjuk: Az egyént és a személyes kommunikációt, a módszertanoknál és az eszközöknél. A működő szoftvert, az átfogó dokumentációnál. A megrendelővel való együttműködést, a szerződéshez való ragaszkodással szemben. A változásra való reagálást, a tervek rigorózus követésével szemben. Hogyan lehet egy műszeripari fejlesztés mégis sikeres? Először is el kell fogadni, hogy nem a fizikai

méretében legnagyobb komponens diktál, hanem a „tömegében” legkisebb (azonban legnagyobb komplexitású) összetevő sajátosságai határozzák meg a projekt alakulását. Beágyazott rendszerekről lévén szó az elektronika és a szoftver szinte azonos súlyúak, viszont a mechanika csupán a harmadik helyre szorul! Bár ez egyszerű következtetésnek látszik, sorozatgyártásra szánt termékeknél mégis nehéz elfogadni, hogy a közvetlen gyártási költség nélküli szoftver és a minimális gyártási költségű elektronika legyenek a „vezérkutyák”. Noha, fontosak az utóbbiak is, mi fontosabbnak tartjuk az előzőeket. forrás: www.agilealliancehu www.agilemanifestoorg Az elmúlt közel egy évtized alatt ezek a célok letisztultak, a forradalom elcsendesedett és a kiáltványban megfogalmazott pontokból elinduló változásokat jónéhány szoftverfejlesztő óriás (IBM, SAP, Google) és beágyazott rendszereket gyártó és fejlesztő cég (Nokia,

Siemens, HP, ) alkalmazta sikeresen. Szemléletváltásra van tehát szükség! Kezdjük el tanulmányozni a szoftverfejlesztés sajátosságait. A minden apró részletre kiterjedő folyamatleírások helyett, empirikus módszerekkel: megfigyeléssel és adaptációval határozzuk meg a soron következő lépést. Ne gondoljuk, hogy a kezdetekkor mindent pontosan tudtunk definiálni, legyünk nyitottak a követelmények és elvárások megváltozására, és tudjunk rugalmasan reagálni a változásokra. A módszertanok és adminisztráció által gúzsba kötött fejlesztők helyett építsünk a személyes beszélgetésekre, a szakmai és technikai kiválóságra és az egyszerűségre. A hangsúlyt helyezzük a működő produktumra Az előrehaladás mértéke legyen a minél több értékes funkcionalitással bíró működő szoftver! 21 Iteratív fejlesztés a műszeriparban Agilis technikák a fejlesztési projektekben Szemben a klasszikus (egyenes vonalú)

fejlesztésekkel, az agilis technikák ún. „iteratív” fejlesztési módszeren alapulnak Az ilyen technikák lényege: a mindennapi személyes kommunikáció a fejlesztők és a projektvezetés között, a gyakori (2-4 hetente) történő egyeztetés a megrendelő (sorozattermék esetén marketing/kereskedők) és a fejlesztés között, gyakori (2-4 hetente) történő belső értékelés, lehetőség szerint működő szoftver vagy készülék alapján, a projekt ciklikus (2-4 hetente történő) újratervezése, figyelembe véve a belső értékelés eredményeit, a változási kérelmek gyors kezelése, szükség szerint azonnali reakció. scrum [scrummage]: a rögbiben a két csapat küzdelme a középen a földre helyezett labdáért Mivel az iteratív fejlesztési elvek a fejlesztők szakértelmén és nem az előírt részletes folyamatterven alapulnak, ezért a projektvezető feladata folyamatosan felügyelni, hogy az egyes lépések a projekt érdekében történnek.

Szigorúan fel kell lépni a „szakmai terroristák” és „kódgyártó cowboyok” ellen. Ez a módszer a „Scrum”, ami a látszólagos káoszban teremt rendet azáltal, hogy a projektvezető és a projekten dolgozó fejlesztők napi vagy heti rendszerességgel értékelik az előrehaladást, és pontosítják a nyitott feladatokat. A módszer alapelemei a következők: Napi vagy legfeljebb heti rendszerességű megbeszélések a fejlesztők és a projektvezetés részvételével, ahol a megoldott és nyitott részfeladatokat értékelik. Az elvégzendő feladatokat a teendőlista, a rendelkezésre álló idő és az aktuális prioritás határozzák meg. A még nyitott feladatok listáját és az átadásig hátralévő időt a mindenki számára elérhető ún. burn-down táblázat tartalmazza 2-4 hetes gyakoriságú futamtervezések a projektvezetés és a megrendelő (marketing/kereskedők) között a soron következő iterációban elvégzendő feladatok specifikálása

céljából. A lehetőleg rövid részfeladatok magyarázattal és prioritással ellátva egy futam teendőlistába (sprint backlog) kerülnek, ahol a projekt bármelyik résztvevője hozzá tud férni. A futam lezárását követő belső értékelés a fejlesztők és a projektvezetés között, ahol az elvégzett, lezárt és letesztelt feladatokat értékelik és véglegesítik a bemutatásra szánt szoftvert vagy készüléket. A futamot lezáró 2-4 hetes gyakoriságú értékelés vagy bemutató a megrendelők felé, mely sok esetben egybeesik a futamtervezéssel. Fejlesztést lezáró értékelés és termékbemutatás. Mivel a változtatásra való igény többnyire nagy, a projektvezető feladata egyrészt a projekt külső hatások előli védelme, másrészt pedig a munka megszervezése és a minőség garantálása: a fejlesztők és a megrendelő (marketing/cégvezetés) közötti kommunikáció szükség szerinti szűrése, változások csak a projektvezető

engedélyével kerülhetnek be a projektbe, a tesztelés nélküli hibás szoftver vagy készülék értéktelen a megrendelő (vagy a marketing/kereskedők) számára, így a cégvezetés sem hasznosíthatja azt, csak a műszaki tartalom változhat a fejlesztés során, a minőség, a határidők és a költségvetés nem kompromisszum tárgya. Az iteratív fejlesztések jellemzője a gyakori változás, ezt a klasszikus projektvezetés hívei sokszor a káosz jelének tulajdonítják. Nem szabad azonban összetéveszteni az agilis módszert a káosszal, a forradalmi kiáltvány nem anarchiát akar teremteni! 22 Iteratív fejlesztés a műszeriparban Jól látható tehát, hogy az iteratív fejlesztés nem valamiféle forradalmi változás, csupán korábbi módszerek adaptálása a szoftverek megjelenése által okozott változásokhoz. Mivel a határidők fixek, a részfeladatok rövidek és az előrehaladás napi kontroll alatt van, így a csúszások minimalizálhatók, a

megrendelők (marketing/kereskedők és cégvezetés) folyamatos visszajelzést kapnak a folyamatban lévő munkákról. Szükség esetén pedig gyorsan készíthető működő készülék Az elmélet a gyakorlatban: Aktuális fejlesztési projektek a NIVELCO-ban Minden elméleti eredmény csak annyira értékes, amennyit konkrétan hasznosítunk. Egy projektvezetési, irányítási modell hasznosságát tehát a sikeresen lezárt projektek jellemzik. A NIVELCO zRt a közelmúltban számos termékét fejlesztette tovább, illetve fejleszti folyamatosan is. Néhány példa a teljesség igénye nélkül: Mivel a kreativitást nem kötik gúzsba az előre definiált részfolyamatok, ezért a csapat sajátjának tekinti a terméket, ez nagyban növeli a motivációt. A változásokra való rugalmas reagálás pedig elengedhetetlen egy piacorientált fejlesztési környezetben! NIVOPRESS -400: Átdolgozott HART interfész, nagypontosságú mérés, digitális kommunikáció és

kalibráció. Védelem túlfeszültség és tranziens zavarok ellen PILOTREK -400: Új fejlesztésű sugárzott nagyfrekvenciás mikrohullámú radar folyadékokra és szilárd anyagokra. NIVOCONT -500: Mechanikailag megerősített kivitel, univerzális tápegység (20-255V AC/DC). NIVOTRACK -500: Rendkívüli pontosság (1 mm-en belül – OMH hitelesítés OIML R85 szerint), 18 méterig megnövelt méréstartomány, grafikus kijelző. MULTICONT PRD: Loggeres kivitel, nagy fényerejű kijelző, USB kommunikáció PC-vel. USB/RS485 – HART modem: Leválasztott áramkör „Ex ia” környezethez, sínre pattintható kivitel. THERMOPOINT -500: Többpontos köteles hőmérséklet távadó silókhoz és folyadékokhoz helyi grafikus kijelzővel. ANACONT -100: Teljeskörű vízanalitikai műszercsalád pH, redox-potenciál, oldott oxigén és vezetőképesség mérésre. Széles szondaválasztékkal és opcionális tartozékokkal NIVOFLIP -100: Bypass rendszerű billenőlamellás optikai

szintkijelző (P.ED alapján engedélyeztetve) opcionális NIVOTRACK távadóval és mágneses szintkapcsolókkal. dr. Kun Gábor Fejlesztési igazgató NIVELCO gkun@nivelco.com 23