Autóipari beágyazott rendszerek Fejlesztési fázis 1
Szoftver és rendszer életciklus Fejlesztési fázisok és módszerek 2
Rendszer életciklus Az autóipari rendszerek életciklusának három fő fázisa van Fejlesztés (3-5 év) Gyártás (3-6 év) Üzemeltetés (>10 év) A rendszert végül megsemmisítik vagy újrahasznosítják 3
Fejlesztés Interdiszciplináris Gépészet E/E (elektromosság/elektronika) Mechatronika Hardver Szoftver 4
Fejlesztés Sok cég együttműködése Autógyár 1. szintű beszállítók (tier 1 suppliers) 2. szintű beszállítók Biztonsági felülvizsgálók Külső teszt cégek 5
Fejlesztés V modell 6
Fejlesztés V modell A fejlesztés koncepcionálisan a V modellt követi 7
Fejlesztés V modell A jármű fejlesztése a legfelsőbb szint, ezt részrendszerekre bontják. Pl. kormányszervó, fékrendszer, Ezeknek külön V folyamatuk lehet 8
Fejlesztés V modell Az autógyár egyik legfontosabb feladata a megkapott részrendszerek integrálása, integrációs és elfogadási tesztelése. Mivel majd minden részrendszer más beszállítótól érkezik, ez komplex feladat. 9
Fejlesztés V modell A részrendszerek V modellje az autógyár követelményeivel indul. Ez általában tartalmaz technikai, precízen megfogalmazott követelményeket, de ugyanakkor időnként nagyvonalú koncepciókat is. A beszállító első feladata a követelmények egyeztetése és pontosítása 10
Fejlesztés V modell Természetesen a valóságban a V modellben visszalépések, iterációk is vannak. Különböző megközelítések vannak arra vonatkozóan, hogy a rendszert milyen lépésekkel fejlesszük. Ezekben a visszalépések gyakorisága, a munkacsomagok nagysága eltérő. 11
Fejlesztés V modell Az úgynevezett Feature Driven Development (funkció alapú fejlesztés) például fő funkciónként vezeti végig a fejlesztést, azaz kisebb egységekre tagolja a rendszert. Minden funkcióval végrehajtja a V baloldalát, míg a tesztelést folyamatosan végzi. 12
Fejlesztés V modell Az iteratív megközelítések először egy nagyvonalú prototípust készítenek, majd ezt iteratívan finomítják, egyre több követelményt elégítve ki. Mivel az autóiparban kiemelt fontosságú a megfelelő tervdokumentáció, és annak ellenőrzése, az iterációk közben ezeket is napra készen kell tartani 13
Fejlesztés V modell Az agilis módszerek, mint a Scrum és a Kanban napjainkban az autóipari fejlesztések területén is teret nyernek. Itt a lényeg az iteratív fejlesztés, összeszokott csapattal, valamint a feladatok tiszta priorizálása és ütemezése. 14
Tapasztalatok A követelmények változnak A vízesés modell és a V modell ezeket nehézkesen kezeli A terv sohasem lesz tökéletes iterációkra van szükség Mikor van készen az implementáció? Ha a fejlesztő azt állítja? Ha sikerül feltölteni a verzió-kontrollba? Ha lefordul? Ha (egyszer) lefut? A dokumentáció és az implementáció viszonya Hogyan tartsuk szinkronban? Honnan tudjuk, hogy szinkronban vannak? Vevői elégedettség Ha csak a projekt végén telepítünk, nem lesz túl késő a panaszra? Mi történik, ha a vevő nem is ezt akarta? 15
Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 16
Mit is jelent az agilis fejlesztés? Individuals and interaction over processes and tools A merev szabályok helyett együttműködés Ne ragaszkodjunk (esetleg elavult) eszközökhöz Az értéket az emberek teremtik! A műszaki fejlesztés intuitív folyamat, ne zárjuk gátak közé Working software over comprehensive documentation Kerüljük a túldokumentálást Ha a dokumentum és a kód 1:1 megfeleltethető, akkor baj van A nagy mennyiségű, előre megírt dokumentáció veszélyes Nem lesz elsőre tökéletes Nem tartják karban Customer collaboration over contract negotiation Adjunk korai visszajelzést Folyamatosan egyeztessük az igényeket Változtassunk a követelményeken, ha a vevő mást szeretne Responding to change over following a plan Ha a környezet változik, a projektnek is változnia kell Általában minden hosszú távú terv változik! 17
Hogyan legyünk agilisek? Több módszertan létezik (pl. SCRUM, Kanban) Fő jellemzők Rövid, jól meghatározott projekt fázisok (sprint) Néhány hét Meghatározott cél Előre definiált feladatok Interaktív tervezés és becslés Projektvezető Vevő Csapat Folyamatos követés Napi csapatmegbeszélések 18
Agilis tervezés (Scrum) Product backlog Minden megvalósítandó funkció (user stories) Sprint backlog Az adott sprintben elvégzendő feladatok Cél: A feladat férjen bele egy sprintbe Mindig a product backlog legnagyobb prioritású elemeit választjuk Sprint tervezés Közös megbeszélés: vevő, projektvezető, csapat Feladatok priorizálása, erőforrás-becslés, erőforrás hozzárendelés Minden sprint elején Az erőforrás becslést és a csapat teljesítőképességét (sprint velocity) az előző sprintek alapján finomítják Daily scrum Napi helyzetértékelő megbeszélés 19
A Scrum Sprint Sprint tervezés Napi Scrum megbeszélés Sprint lezárás (retrospective) 20
Technikai eszközök Folyamatos integráció A termék folyamatosan épül Az új változások belekerülnek Egységtesztek lefutnak Elfogadási tesztek lefutnak Hiba esetén azonnali reakció Egységtesztek Automatikus tesztek Gyorsan lefuttatható Folyamatosan karban tartott Páros programozás Egy gép két fejlesztő négy szem többet lát Azonnali kód ellenőrzés 21
Technikai eszközök Tesztvezérelt fejlesztés Alapelv Csak akkor írj kódot, ha van (legalább) egy nem teljesülő teszt Következmény Először tesztet írunk! Minden esetben lesz egy jó kódfedést elérő teszt készletünk Minden refactoring után ellenőrizhetjük a funkcionalitást Kiegészítések Ha egy bukott teszt miatt kódot módosítunk, rakjunk is rendet (refactoring) A teszteket is tartsuk tisztán (nincs kód duplikáció, stb.) Gyakorlati megfontolások Ha jó eszközünk van, nem lassítja a munkát (sőt) Tudjuk, hogy mikor vagyunk kész (minden követelmény tesztelt) Mindig tudjuk, hogy működik-e a kód Az így elkészült egységteszteket a folyamatos integráció során is futtatjuk GUI esetén nehézkes lehet 22
Technikai eszközök Folyamatos integráció Szerver jellegű funkció Ütemezett feladat végrehajtás Minden változás esetén (verzió kontroll) Periodikusan (pl. minden nap éjfélkor) Feladattípusok Forráskód letöltés a verziókezelőből Szoftver fordítás Dokumentáció generálás (Doxygen, Javadoc) Futtatható fájl elkészítése Egységtesztek futtatása Elfogadási tesztek futtatása Eredmények publikálása Szoftver publikálása 23
Technikai eszközök Fejlesztőkörnyezet Nagyban befolyásolja a produktivitást Fő funkciók Kód szerkesztés Syntax highlight, code completion, Fordítás Teszt futtatás Refactoring Minél hatékonyabb, annál termelékenyebbek leszünk! 24
Scrum státusz Meg nem Folyamatban kezdett levő Elkészült feladatok A feladatok feladatok sprint célja A hátralevő munkamennyiség grafikonja Nem tervezett Nem lesz kész feladatok 25
Agilis technikák - összegzés Megfelelő technikai környezetben hatékonyak Újszerű megközelítés, ezért nagy a kezdeti ellenállás Segít a projekteket időben teljesíteni Gyorsan lehet reagálni a változásokra Módosítani lehet a tervet, ha változnak a prioritások Minden projekt tagnak tiszta képe van a státuszról Webes/mobil fejlesztéseknél elterjedt Az autóiparban is vannak már kezdeti sikerek Össze lehet egyeztetni az agilitást a biztonságkritikus rendszerekkel! 26
Fejlesztési fázisok Előfejlesztés / prototípus Egy új technológia vagy funkció kipróbálása Nem cél a tökéletesség Nem cél a biztonsági szabványoknak való megfelelés Fő cél: demonstrálható funkcionalitás Jellemző eszközök Hibrid vezérlőegység Meglevő eszköz módosítás, piggy board, Gyors prototípus hardver Nagy számítási kapacitású univerzális hardver Gyorsan programozható Viselkedési modelleket is végrehajt (Simulink) 27
Fejlesztési fázisok A minta fázis A sorozat fejlesztés első lépcsője A meglévő építőelemekből összeállított koncepció validátor Gyakran nem kerülhet járműbe Cél Méret Ellenállóság Összeszerelés A kiválasztott részmegoldások együttműködésének bemutatása Szoftverfejlesztés korai támogatása Funkcionális demonstráció akár tesztkörnyezetben Gyártás Gépi vagy kézi beültetés, sok kézi lépéssel, kézi összeszerelés 28
Fejlesztési fázisok B minta fázis Gyártásérett mechanikai és elektronikai megoldások Járműbe szerelhető Minden környezeti hatásnak ellenáll (aminek a végtermék is) Cél A véglegeshez közeli terv érvényesítése Járműtesztek Szoftver funkcionálisan teljes Minden diagnosztikai funkció is működik Akár közúton is használható Gyártás Kis sorozat, gépi beültetés, kézi elemekkel 29
Fejlesztési fázisok Design Validation tesztek Céljuk a design ellenőrzése Funkcionálisan Élettartam szempontjából Környezeti hatásoknak való ellenállás szempontjából Határhelyzetbeli működés ellenőrzése Első EMC mérések Tipikus tesztek Élettartam teszt Sóköd kamra Rázópad Klímakamrás tesztek Stressz tesztek (fordított táp, ) 30
Fejlesztési fázisok C minta fázis A B minta tapasztalatai alapján finomított megoldások Járműbe szerelhető Minden környezeti hatásnak ellenáll (aminek a végtermék is) Cél Fejlesztés lezárása Szoftver finomhangolás, kalibrálás EMC optimalizálás Gyártás Nagyobb sorozat, a végső gyártó gépekkel, de még nem szalagszerűen 31
Fejlesztési fázisok D minta fázis Minden optimalizálást tartalmaz Járműbe szerelhető Minden környezeti hatásnak ellenáll (aminek a végtermék is) Cél Felkészülés a sorozatgyártása Végső tesztek elvégzése Elfogadtatás a vevővel Gyártás Nagyobb sorozat, a végső gyártó gépekkel, a végső folyamat szerint 32
Fejlesztési fázisok Process Validation teszt Cél A gyártási folyamat érvényesítése Főleg élettartam teszt alapon Kiindulópont: funkcionális ellenőrzés már a DV-ben megvolt A gyártási folyamat az élettartamot befolyásolja leginkább Ezen kívül Termikus viselkedés mérése EMC mérések vevői elfogadás feltétele 33
Érettségi szintek A rendszer érettségét adják meg Függ A mechanika állapotától A hardver megbízhatóságától, gyártási körülményeitől A szoftver tesztek és analízis állapotától Gyártófüggő lépcsők Legalacsonyabb: csak tesztpadon alkalmazható Alacsony: csak tesztpályán használható, kiképzett sofőrrel Közepes: közúton is használható, kiképzett sofőrrel Magas: bárki vezetheti bármely körülmények között Külön korlátozások lehetnek Például: élettartam, hőmérséklet tartomány, 34