Collegamento: http://metriche-per-il-software-pa.readthedocs.io/it/latest/documento-in-consultazione/metriche-e-strumenti.html
Contenuto:
4 Metriche e strumenti
4.1 Importanza delle metriche di prodotto
4.2 Misure funzionali
4.2.1 Misure funzionali automatiche
4.3 Misure non funzionali
4.4 La norma ISO 25023
4.5 SNAP
4.6 CISQ-OMG
Suggeribile trattare le misure automatiche in modo consistente in un’unica sezione al termine del documento e non nella sezione 4. E’ fondamentale specificare il contesto d’uso per i tool al fine di poter dar loro un giusto posizionamento nella gestione del progetto: un tool velocizza ma non può sostituire l’attività di elicitazione requisiti e il relativo dimensionamento, funzionale e non.
Ad esempio, un conteggio di massima per un sistema legacy, ma sempre con verifica finale di un CFPS/CFPP o CCFL (nel caso di conteggi con il metodo COSMIC), in particolare per la corretta definizione di ambiti e confini applicativi.
In generale i tool possono trovare valida applicazione ‘ex-post’ e non ‘ex-ante’: la FPA nasceva nel 1979 per permettere le stime già in fase di analisi e quindi prima della fase di codifica. Nel 2018 si affermerebbe quindi che un tool permetterebbe di raccogliere i requisiti e determinare il valore in FP di una CR ancora da sviluppare?
Tali soluzioni automatiche sono quindi valide solo per casi ‘ex-post’ e tramite un parsing del codice, da specificare.
La sezione 4 attualmente denominata “Metriche e Strumenti” sembra - con la strutturazione attuale - mescolare i due temi. Ora esiste una §4.2.1 senza una §2.4.2 e poi si riprende nella §4.6 altro pezzo di trattazione solo per CISQ/OMG, mentre - come per gli aspetti di metodo - andrebbero sempre proposti più casi, in questo ambito di tipo OSS, non solo direttamente commerciale, per ogni confronto (es: Jira, SonarQube, …): suggeribile pertanto una sotto-sezione dedicata solo ai tool dopo aver introdotto le misure (metodo), con un adeguamento del testo in tal senso per offrire una panoramica più completa ai lettori del documento.
Sez. 4.2.1: gli AFP contano ex-post quattro (4) e non cinque (5) BFC IFPUG, quindi fuori standard IFPUG (come inserito nella nota 15) anche per un conteggio comparativo di baseline che DEVE essere sul dettaglio, non solo sul numero complessivo di FP. Altrimenti per molti contratti potrebbero esserci problemi di costizzazione relativi alla attuale differenziazione di prezzo tra un elemento di tipo ADD, CHG, DEL.
Per il cap 4.4 proposto su GitHub la revisione delle metriche di accessibilità. La versione finale pubblicata della ISO porta 2 indicatori e non 5.
Si sta affermando che uno o più tool permetterebbero di raccogliere requisiti, determinare il valore in FP di una CR ancora da sviluppare?
Tali soluzioni automatiche sono utili solo dopo il lavoro di un CFPS altrimenti non ha senso affermare che l’utilizzo dei FP è ancora corretto. Bisogna rispettare gli standard della FPA.
La nota 15 riporta che gli algoritmi proposti da OMG non sono stati validati da IFPUG. La nota va portata in evidenza nel corpo del capitalo e soprattutto sarebbe corretto fare prima delle sperimentazioni sugli applicativi della pubblica amministrazione e analizzare il risultato ed in un secondo momento validarne i risultati secondo lo standard FPA. Uno standard già esiste ed è utilizzato. Non ha senso effettuare dei conteggi con processi automatici non validati e non verificati da CFPS.
Nel capitolo 4 si consiglia di togliere il paragrafo 4.6 che non parla di metriche ma fa riferimento alla trattazione di NFUR di una IT industry.
La metrica SIn-3-S “Validità degli accessi alle strutture dati (array)” potrebbe riguardare l’accesso ad un array mediante un indice non compreso nei limiti (out of bounds) dell’array stesso, che in alcuni linguaggi di programmazione causa comportamento indefinito con possibile corruzione di dati.
Il documento da noi utilizzato come riferimento (https://www.iso.org/standard/35747.html) a pagina 24 (tabella 14) riporta 5 indicatori. E’ possibile che sia stata rilasciata una versione successiva del documento alla quale noi non abbiamo avuto accesso.
Assolutamente no.
Riporto un passaggio del paragrafo 4.2.1: “L’Object Management Group (OMG) ha approvato nel 2014 la tecnica AFP (Automated Function Point) definita da CISQ per la misurazione automatica della dimensione funzionale del software. Tale tecnica, sviluppata sulla base del manuale di conteggio IFPUG versione 4.3.1, prevede che la misura sia effettuata sul codice sorgente e sulle strutture dati, tramite algoritmi di riconoscimento delle transazioni applicative, alle quali vengono applicati gli stessi criteri di IFPUG per ciò che riguarda la classificazione dei componenti funzionali (BFC) e l’attribuzione della complessità agli stessi.”
Come vede, si dice esplicitamente che che la misura va effettuata sul codice sorgente e sulle strutture dati. Quindi si tratta evidentemente di una misura “ex-post”, come del resto più volte precisato in vari altri passaggi presenti nel documento.
@giovanni_di_iasio Si, erano presenti 5 indicatori nelle versioni in bozza. Quella finale (life cycle 60.60) a pagina 19, tabella 14, riporta ora solo 2. Saluti,