[Javalist] Csatolások szoftverekben

[Gábor Garami]

Ezzel a magyarazattal csak egy bajom van, hogy nem eleg eletszagu. Eloszor
is, a hibak azok nem csak ugy altalaban vannak, hanem van hiba es hiba
kozotti sulyozas is. Pl szerintem egy webappnal pl hiba az, ha egy gomb
szine mas, mert a szinkod el lett irva, ugyanakkor a projektre kihatasa
nulla. Egy validacio kimaradasa nagy security hiba, de a projektre hatasa
ugyancsak nincsen.

Szoval itt felmerul a kerdes, hogy nem kellene esetleg a hibakat sulyozni?
Hany elutes er egy security hibat? Hany security hibat er egy rossz
pattern? Mert sztem ezek fontos kerdesek.

Egy hiba "erteket" sztem elsosorban a kijavitasahoz szukseges energia adja
meg (hiba megtalalas+javitas). Egy masik ertek, hogy az adott hiba milyen
mertekben eredeztetheto tervezesi/szemleleti hibabol. Ez a ket szam mar
segit sulyozni a hibakat. Minel magasabb ez a ket szam, annal nagyobb
problemak vannak a rendszerben. No persze, ez csak a problemat vilagitja
meg, nem pedig a megoldast, de vhol mindent el kell kezdeni.

Udv,

Garami Gábor
gabor.garami at hron.me
Skype: hron84
Tel: +36 20 235 9621

Sent from my T-Mobile G2
Ezt a levelet telefonról adták fel, ékezethibákat tartalmazhat.
2012.05.19. 18:15, "Molnár Miklós" <timortinj at freemail.hu> ezt írta:

> Hali,
>
> Nagy küzdés után azt hiszem megtaláltam a szóbanforgó részleteket
> tartalmazó
> cikke(ke)t.
>
> Columbus: A Reverse Engineering Approach
> http://star.fbk.eu/step2005/paper3.pdf
>
> New Conceptual Coupling and Cohesion Metrics for Object-Oriented Systems
> http://www.cs.wm.edu/~denys/pubs/SCAM'10-CohesionCouplingMetrics.pdf
>
> Akik nem akarnak elmerülni a részletekbe azok számára (meglehet torzított)
> rövid értelmezésem az alábbi.
>
> Adott a szegedi egyetem által több éve kifejlesztett Columbus nevű, C/C++
>  -
> szoftverminőséget 58 db metrikán keresztül mérő - reverse engine framework.
> A Symbianra is ezt engedték rá tehát.
>
> Az új cikk két új metrikát vezet be a régiekből kiindulva (és az előadás
> ennyiben félrevezető volt, mert ennek egyszerű(bb) a matekja,  mint ott
> látszott, azaz mindenkit buzdítok olvassa el a cikket, mert érthető)
>
> (1) Conceptual Coupling between Object classes (CCBO)
> (2) Conceptual Lack of Cohesion on Methods (CLCOM5)
>
> * Reverse Engine Columbus-szal (cikkben Mozilla projektre)
> * Korpusz-építés az alábbiakra (+stoplista: a "the" például ignorálandó)
> (1) comments
> (2) local and attribute variable names
> (3) user defined types
> (4) methods names
> (5) parameter lists and
> (6) names of the called methods.
> * Latent Semantic indexing (LSI) szövegbányászati metódus alkalmazása
> * Ezután megkaphatók a releváns kapcsolatok metrika-kalkulálással,
> alkalmazással
> * Elő kell venni a Mozilla hibaadatbázisát
> * Meg kell nézni, hogy a releváns kapcsolatok hogyan függnek össze a
> hibákkal
> * prediktív analitika széles tárházával (Weka, 12 algoritmus)
> szembesítették
> az immáron 61 db szoftver metrikát -> melyik metrika a legjobb
> hibaelőrejelző (hibahajlam-feltáró)
> * Ez vezet a végső előadói konklúzióhoz: túl sok csatolás túl sok hibához
> vezethet, ami jobban valószínűsíti a kiváltást.
>
> Konklúzióm (nem fog szeretni érte a levlista)
> =============================================
>
> Tiszta világos gondolatmenet a fenti. Az egyedüli meggondolandó az
> érvényességi tartomány.
>
> Lehet "lázadni" az ellen, hogy a hibák azért vannak, hogy kiküszöböljük
> őket, meg amúgy is csak az egyszerű emberek raknak rendet, mint tudjuk a
> "zsenik uralják a káoszt".
>
> Én mégis azt mondom, ahogy a való életben a túl sok hiba elbocsátáshoz
> vezet
> a munkahelyen, úgy a szoftverben lévő kritikus tömegű hiba a szoftver
> kiváltási presszióját növeli. Ennyi. Nem több és nem kevesebb.
>
> A hibákat meg nemcsak kinyilatkoztatás szintjén kell kerülni, hanem
> rásegíteni hasznos eszközökkel. Szükséges, de nem elégségesen hasznos, ha a
> hibákat elektronikusan dokumentáljuk. Ha "ezrével" rögzítünk be hibákat ezt
> támogató rendszerekbe, az önmagában már deprimálóan hat és rontja a
> hibajavítás hatékonyságát. Én voltam nem egyszer résztvevője olyan
> projekteknek (harmadik legutóbbi itthon Magyarországon(!) 1.400 ETL-job
> verzióváltásos migrálása, 10.000-es nagyságrendű tárolt eljárással, olykor
> többezer kódsorral elég kevés emberhónap alatt, de legutóbbi két projektem
> is ilyen alapokon volt problémás redesignjai elött: valahogy tehát én
> vonzom
> ezeket) ==> ahol túl sok hiba merült fel túl kevés idő alatt az egész
> projektet alapjaiban megrengetve.
>
> A tárgyalt potenciális eredmény/lehetőség, a csatolások számának
> csökkentése. Egybevág az eddigi szemlélettel (nem kell paradigmaváltás),
> kárt nem okoz, maximum valamennyi ráfordítási igénye van. Mindenki
> mérlegelheti ezt cost-benefit alapon, támogatja-e a munkájában.
>
> Én a magam részéről letettem a voksomat (már régóta akkor még pusztán csak
> intuitiv alapon), hogy megéri a "lineáris" erőforrásigényű befektetést,
> potenciálisan progresszíven növekedő komplexitás és hibaszaporodás
> elkerülése érdekében.
>
> MM
>
> PS: Végül az egész egy újabb blogposztba torkollt.
>
> http://liftinstinct.blogspot.com/2012/05/csatolasi-metrika-szoftverekben.htm
> l
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20120521/b875cc88/attachment.html>