kvp#13
"Egész pontosan csak a szoftver fejszerésben használják iterative development-et."
Nem csak ott. Hardvernel is. Neha meg eletkritikus hardvernel is (orvosi muszer). Sot gyakran a meg a sorozatgyartas soran is optimalizaljak a koltsegeket, neha behozva egy-ket uj hibat. Anno elso multis munkahelyemen el is hangzott, hogy ha 100 betegbol csak 1 hal meg szoftver vagy hardver hiba miatt, az jo arany. En nem tartottam annyira jonak, de ha egy nagy amerikai ceg megengedheti ezt maganak, akkor ez a realitas.
Egyebkent beagyazott mernokkent teljesen normalis, hogy neha at kell tervezni egy-egy hardvert, ezert vannak a prototipusok, hogy megtalaljuk azokat a hibakat amiket a tervezes soran nem lehetett kikuszobolni. Legyen az a felhasznalt egyik komponens ismeretben hibaja (ezekbol szuletnek aztan a hardveres erratak, amiket probalnak kesobbi reviziokban javitani), amiket attervezessel tobbnyire meg lehet kerulni ha nem akkor komponenst kell cserelni vagy legyen a szoftver eltero viselkedese a fizikai kornyezetben a tervezett/szimulalt kornyezethez kepest. Neha egy szoftveres problemat a hardver attervezesevel a legegyszerubb kijavitani. Ezt csinaltak egyebkent az Apollo kuldetesek soran is. (a 11-es es 12-es kozott atterveztek az AGC hardveret a 11-es leszallasanal elojott tervezesi hiba reszben kijavitasara, reszben megkerulesere, meg szerencse, hogy az egyetlen civil tesztmernok ment vele)
Meg autoknal is ezert vannak a prototipusok, hogy lehessen hibazni, lehetoleg meg a szeriagyartas elott. De ugyanez igaz egy uditos dobozra is, csak ott valamivel kisebb a hibalehetoseg. Magyarorszagon is epultek proba lakotelepek, hazankent eltero megoldasokkal es az igy nyert tapasztalatokbol keszultek a kesobbi szeriagyartott hazak. Ez mind az iterativ fejlesztesi modell alkalmazasa a gyakorlatban.
"Milyen elvet követhetne még egy rakéta, és milyen más formája lehetne?"
Az R7 a Korolev kereszttel egy eltero elv, a kinai hordozok is azt kovetik. (az uj kinai uralomas fellovesenel a videon is jol latszik, hogy nagyon szep Korolev keresztet dobtak a booster-ek) Aztan ott van az N1 raketajuk, aminek mar a formaja sem volt jo, de a nem onhordo, gomb alaku uzemanyagtartalyok sem jo megoldasok. Aztan ott van a falcon heavy es az ariane 5 barkacs megoldasa, amikor tobb kisebb raketat kotoznek ossze, ami messze nem idealis. Es akkor az ursiklok barkacs megoldasairol meg nem is beszeltunk. Szoval a letisztult forma nem jellemzo minden raketara, de fel lehet ismerni a V2 - Atlas - Saturn - Falcon 1 - Falcon 9 - Starship vonalban az idealisnak tekintheto megoldas hasznalatat. Persze van akinek mas jon be, pl. a Korolev fele parhuzamos 4 booster-es, 1.5 stage-es megoldas konnyebbe teszi a staging-et, de cserebe nem idealis a rendszer hatekonysaga es a raketa legellenallasa a booster levalasztas elott. Persze az ursiklo fele oldalra odakotozott repulo teglahoz kepest fenyevekkel jobb. Szoval nem, a raketamernokok szamara sem trivialis az idealis forma.
A Spacex a crew dragon-nal es az uj cargo dragon-oknal felhasznal egy regi (gorog) geometriai szabalyt, ami javitja a hatekonysagot es csokkenti a terhelest max q-nal, de az amerikai konkurensek kozzul se a starliner, se az artemis kapszula tervezoi nem ismertek fel. (a sojuz pedig burkolattal indul, ott nem szamit) A blue origin sem jott ra, de ok legalabb megprobalnak mindent lemasolni, tehat lehet veletlenul ezt is sikerul majd. Nem irom le micsoda, de a lenyeg a kapszula formajaban van. (a spacex is hallgat rola, meg szabadalmat sem adtak be ra)
"Egy rakétamérnök mélyreható ismeretekkel rendelkezik, amihez képest visszalépés lenne a "trial and error" módszer,"
Ezt reszben test driven development-nek hivjak, ami az iterativ tervezes egyik modernebb valtozata. Hardveres kornyezetben igy jutunk el a deszka modelltol (a szo szerint deszkara szogelt alkatreszektol) a kesz termekig. Ezert van az, hogy pl. a Boeing-al szemben a Spacex minden alrendszert letesztel meg indulas elott, eloszor kulon-kulon, aztan integralva. Viszont eles repulesi tesztet csak repules kozben lehet vegezni. Az osszes tervezoasztalon "tesztelt", bizottsagok altal tervezett jarmu tele van tervezesi hibakkal, amiket ki lehetett volna kuszobolni ha mertek volna ujratervezni amikor egy hiba elojott. Pl. az ursiklo elso utjanal kijott a hovedo csempek lehetseges serulese, de csak a feher festek elhagyasaval es az inditasi homerseklet es paratartalom limitalasaval probaltak tenni ellene, de nem terveztek ujra az egesz jarmuvet, mert tul keso volt mar a hagyomanyos vizeses modell szerinti fejlesztes soran. A Spacex mer hibazni, es utanna mer teljesen ujratervezni valamit ha nem felel meg az elvarasoknak. Az evolucio is pontosan igy mukodik, neha erdemes tanulni belole.