( turul16 | 2008. 05. 14., sze – 22:26 )

Ettol bonyolultabb az egyenlet.
Valoszinuleg kijon, hogy a hosszan karbantartott valtozatok megbizhatobbak egy kicsit.

Alapvetoen ugy szoktak kalkulalni, hogy az l soros szofvarben van n hiba.
A teszteles/hasznalat soran t ido alatt a hibak p reszet ]0.0..1.0[ talaljak meg. A kov t ido intervallumban a maradek p reszet .. stb. (Ez fugg a teszterek szamatol, hibatalasi kepesegeitol) (ebbol lehet diff egyenletet karcolni)

Az egyenlet tovabb bonyolodik, hogy gyakorlatilag ugyan arrol a szoftverrol van szo, de L sor megvaltozott, es feltehetoleg hasonlo sor/hiba aranyban kerultek hibak, mint az elozo verziokba.

Egy olyan szoftvernel amiben hiaba van 10000 hiba felhasznalok nagyobb resze nem talalkozik egyikkel sem, felfedeznek mondjuk 9000 belole es javitjak (mondjuk 1 ev alatt), akkor egy ujabb l/L<0.01 kodvaltoztatas mondjuk hozz 100 uj hibat. Amiek felet par heten belul javitjak. Maradek elhuzodik. Igy mondjuk 1050 vs. 999 rejtett hiba lehet morfondirozni.

Feltehetjuk azt is, hogy fejlesztok is tanulnak es tesztelok (userek) szama is novekedett..
(Ha szofware felhasznali szama novekszik, a hibak felfedezesenek sebbesege is novekszik.)

Most nincs kedvem szamolni..
Hagyhatjuk is, mert ez meg mindig nem a teljes kep :)