Please enable JavaScript.

Coggle requires JavaScript to display documents.

1 - INTRO, SNORING, PROPORTION, DEFECTIVES, PROPORTION / LEVERAGE DEFECTS …

- - - - SCALE
        
        Parliamo di scala se, data una coppia <oggeto fisico, oggetto formale>, a cui associo una misura 'm', allora le relazioni da A equivalgono a quelle da B, e per ogni operatore in A ho operatore in B
        
        Scala Nominale: do un nome alle cose, posso solo parlare di uguaglianza.
        esempio: "Luca" != "Matteo", non posso dire altro
        
        Scala Ordinale: i nomi sono dati in ordine particolare, posso solo confrontare tale ordine.
        Esempio: "Oro" migliore di "Argento", ma non posso dire di quanto, non posso dire 5 argenti = 1 oro!
        
        Scala intervallo: associo numeri per rendere significativo un intervallo, devono avere senso (es: voti vanno da 0-30, o gradi Celsius)
        
        Scala rapporto: rapporto tra misure.
        Esempio: v = m/s
        
        Scala assoluta: quando posso misurare in UN SOLO MODO un oggetto! (es: in casa ci sono 5 persone, ho 25 linee di codice, non esistono modi diversi per contarle!
      - MODELLI DI PREDIZIONE
        Avremo a che fare con classificatori (supervised categorical/classification).
        
        L'input è numerico, la predizione è nominale (tempo bello/brutto; si/no)
        
        Spesso l'ouput è proprio il modello di predizione/classificatore!
- - - - FAILURE VS DIFETTO
        
        La failure viene vista dall'utente, se esiste allora c'è un difetto/bug nel software.
        
        Il difetto, che è un bug nel sw, non implica una Failure osservabile dall'utente.
        
        Graficamente:
        FAILURE :arrow_right: DIFETTO
        DIFETTO :arrow_right: :red_cross: FAILURE
      - La release 2 è buggy? (quindi la colonna!)
        
        DIPENDE DA DOVE MISURO:
        se misuro in r3 (all'inizio) C1,C2,C3 hanno degli 'Injected' non risolti.
        Se mi metto in r4 (= fine r3) questi 'Injected' sono risolti!
      - SNORING CLASSES
        "So dell'esistenza di un difetto solo dopo averlo fixato".
        Anche se io lo 'osservassi', non saprei dire nulla su di lui. Solo quando lo fixo so tutto su di lui!
        
        Injected Version: release dove nasce il bug
        
        Opening Version: release in cui scopro il bug, la release è individuata dal ticket aperto per il bug.
        
        Fixed Version: release in cui risolvo il bug
        
        Affected Versions AV = insieme di release che fanno dalla Injected Version inclusa alla Fixed Version esclusa, cioè AV = [IV, FV)
        
        Difetto dorme finchè non viene scoperto, ovvero [IV, OV)
        
        Snoring presente nelle release più recenti, dati ancora non maturi.
        
        Lo Snoring cambia a seconda della release in cui mi metto per misurare: normalmente una predizione fatta in una release x viene 'cambiata' da una predizione fatta in una release x+1 se questa include il primo fix sulla classe.
        
        In parole povere, se in r1 ho 'I', in r2 'N' e in r3 'F' allora osservando da r3 le considerazioni su r1 ed r2 cambiano. Perchè? Perchè se introduco il Fix in r3 allora le release precedenti erano buggy, ma prima di introdurre questo fix non potevo saperlo!Se in r4 aggiungo 'I' e fixo in r5, le considerazioni da r1 a r3 non cambiano.
        
        Da Falsi negativi (dico NON buggy ma è buggy), NON falsi positivi (dico BUGGY ma non lo è)
        
        Le classi toccate dal fix sono buggy
        
        Le ultime release dei progetti tendono ad avere poche classi buggy, ma solo perchè i dati devono ancora 'maturare'.
        
        PER PARLARE DI IV, IL BUG DEVE ESSERE FIXATO, NON BASTA CHE SIA SOLO SCOPERTO!
        
        Ragionando, scoprire un bug non implica sapere dove sia situato, per capirlo devo trovarlo, ma se lo trovo allora lo correggo.
        
        OV dice solo 'ho trovato un bug, succede questa cosa', non mi dice perchè e dove, sennò sarebbe FV.
        
        Le Snoring classes possono dare FALSI NEGATIVI, ovvero:
        
        Ipotizzo che classe sia NON Buggy (perchè dico 'negativo') ma invece è buggy (perchè la risposta è 'negativa').
        
        NON HO FALSI POSITIVI, ovvero:
        Ipottizzo che la classe sia buggy (perchè dico 'positivo') ma non è buggy!
        
        In pratica se una classe è buggy lo è perchè ha qualche caratteristica 'particolare' (come tampone covid), può succedere che non trovi quella caratteristica, ma se la trova è per forza buggy ( e covid!)
        
        Ovviamente può capitre che il fix dia falsi negativi, ovvero non ho risolto il bug/ ne ho introdotto un altro!
        
        INTRODUZIONE A SZZ: ASSOCIO DEFECT-CLASS
        
        Creo un ticket per un bug. (JIRA)
        
        Creo un commit (GIT), associato a ticket del bug.
        
        Scopro la riga che è stata modificata nel commit, ovvero quella che aveva il bug.
        
        Due riflessioni:
        :red_cross: se non avessi cambiato quella riga, non avrei trovato il bug, avrei pensato che la classe era senza bug.
        :red_cross: ho fixato il bug, per quante versioni il bug c'era? Cioè come capisco quando il bug è stato introdotto? Magari quella linea di codice fixata ha subito più modifiche nel tempo. Come capisco quale modifica ha portato il bug?
        
        SZZ
        
        Sfrutta il blame (operazione per scoprire quale commit ha introdotto il bug, andando a vedere la release precedente). Ovvero vado indietro nelle release fin quando la linea di codice (LOC) buggy è stata introdotta.
        
        Fixo una riga di codice in V3, quindi V2 era defective, ma V1? potrebbe avere una riga ancora diversa, o non averla.
        V1 dovrebbe essere come V3 per non essere buggy! (se fixo i<=4, nelle release prima posso avere sempre i<=4 e quindi andavano bene, oppure una condizione diversa da questa, e trovo la prima!)
        
        SVANTAGGI
        :red_cross: se introduco feature e non funziona, sono costretto a cambiare quello che funzionava per far funzionare questa feature.
        SZZ direbbe che il bug è nella classe che funzionava, anche se prima il problema non c'era. creo REGRESSION BUG
        :red_cross: il blame va solo una volta indietro, magari non basta.
        :red_cross: se cambiamenti al codice non aggiungono nulla (refactoring/zucchero sintattico) potrebbero essere individuati come blame (es: i<6, i<=5). Alcuni tools cercano le modifiche funzionali.
        :red_cross: Non posso considerare casi in cui il bug esiste e non è stato ancora fixato. Quindi SZZ funziona solo con bug che sono stati fixati, solo con esso capisco se classe è buggy o no! In altre parole assumo di toccare cose non 'rotte'
        :red_cross: Se un requisito cambia, non posso fare ipotesi sulla bontà della linea di codice tramite SZZ
        :red_cross: Un commit potrebbe cambiare qualcosa di rotto e di non rotto insieme.
        :red_cross: Se il fix è fatto aggiungendo solo codice senza toccare altro, non trova nulla.
        :check: Rispetto a Leveraging ha RECALL PIU' ALTA, perchè non usando le AV va indietro fino a che non trova quando la LOC è stata 'creata', mentre in Leveraging si cerca solo nelle AV.
        
        SVOLGIMENTO TEMPORALE
        
        Viene inserito un difetto su GIT.
        
        Viene scoperto e creato un ticket su JIRA. il ticket è del tipo <ID, tipo,bug, descrizione>
        
        Quando si corregge il bug, si lega il fix su GIT all'ID del ticket JIRA, questa è l'unica informazione fondamentale che non deve mancare!
        
        TROVARE BUGGY CLASS
        
        Vado su JIRA, trovo bug chiusi, prendo ID, prendo i commit associati a tali ID, prendo le classi toccate da ID (e quindi dai commit). Quelle erano classi DEFECTIVE, ma con tale fix non lo sono più!
        
        SNORING
        Senza un fix la classe è NON BUGGY, però potrei scoprire che la classe era BUGGY nel futuro.
        
        Una classe è SNORING se non ha nessun bug fixato e ha almeno un bug fixato al momento della misurazione.
        
        Classe Snoring se sembra NON BUGGY, ma è BUGGY (falsi negativi).
        
        Se una classe ha un bug dormiente ed uno no -> NON è SNORING CLASS; perchè grazie al bug non dormiente etichetto la classe come defective ( è true positive, ovvero mi aspetto sia buggy e lo è).
        
        MISURAZIONE
        Quando voglio vedere classi defective o no, mi metto sempre all'inizio della release che considero.
        
        se in <c1, release1> ho 'injected', e a inizio release2 non fixo nulla, vedrò la classi in release 1 come ND. (dormiente)
        
        se in <c1, release 1> ho due 'injected', in release2 ne fixo solo uno, quindi vedrò la classe come Defective. (NON dormiente)
        
        se in release3 ho un fix che coinvolge <c1, release 1> (caso iniziale) allora c1 in release 1 ha snoring.
        
        Se trovo bug in v8, e iv = v3 allora da v3 a v7 sono buggy.
        
        NEL DETTAGLIO
        Suppongo di avere x release, se le prendo tutte ho più snoring. Allora devo prenderne di meno, ma quanto di meno?
        Voglio vedere come cambia l'accuratezza:
        
        missing rate = FN/(FN+TP), ovvero i falsi negativi ( cioè positivi) diviso tutti i positivi (quelli che lo sono effettivamente + quelli che penso non lo siano ma in realtà lo sono)
        
        progress = release misurate/totale, quindi ad esempio misuro il primo 5% del dataset in diverse release future (se ho 10 release, misuro le prime due osservando da r3 a r10)
        
        1 more item...
        
        LEVERAGING DEFECTS
        
        E' un meccanismo diverso da SZZ (è una alternativa), ma si parte dal ticket di JIRA e fixato da commit.
        
        Senza fix non parlo di labeling, perchè non ho il concetto di bug, che è noto dopo il fix (ovvero con il fix so quale riga è problematica!)
        
        Il nostro obiettivo è creare un dataset valido per le predizioni.
        
        Si introduce il labeling (etichettare), ovvero identifico classi passate come buggy o non buggy.
        
        Serve AV, se non lo ho, e non voglio usare blame, come faccio? Mi serve
        
        DEFECT LIFECYCLE
        Abbiamo già visto i concetti di IV, OV, FV ed AV.
        
        Prima di IV le versioni non hanno quel bug.
        
        Dopo FV le versioni non hanno quel bug.
        
        Posso trovare IV, se non presente?
        
        Nei nostri studi lavoriamo con Bug chiusi e risolti, che hanno un fix commit e che hanno post-release defects.
        
        CASI BORDERLINE
        
        Se FV != OV, OV è buggy?
        Si, perchè il bug è osservato
        
        IV viene sempre prima OV?
        Si, altrimenti scoprirei un bug che non è mai stato messo
        
        FV può essere buggy?
        No, per definizione non può
        
        Posso avere IV = OV
        Si, è il caso limite.