ING SOFTWARE 2 06/07 [TOPIC UFFICIALE]

Quando si parlava di flow graph la domanda è errata nel senso che si tratta di una domanda sull'information flow (!=flow graph ovviamante), che è una metrica di modularità ovvero un sottoattributo dell'atributo di qualità modularità.

Si ottiene dall'osservazione della structure chart
Si misura con Fan-in, Fan-out e indice H&K (Henry & Kafura)=(Fan-in*Fan-out)^2.

Misura la complessità del prodotto e del singolo modulo, basandosi sulle connessioni tra moduli che avvengono attraverso interfacce e accessi a variabili globali.

Può essere utilizzata per identificare:
-colli di bottiglia nel sistema (o parti critiche)
-potenziali problemi nel progetto

Un modulo con alto fan-in/fan-out probabilmente appartiene al nucleo.

theone84 ha scritto:

theone84 ha scritto:

Rizzi ha scritto:

Comunque stiamo attenti sullo static testing.

Secondo il syllabus sia walkthrough che inspection sono modalità che testano le fasi di specifica e progetto preliminare...il wiki canna di brutto!

questa è una grande incongruenza...mi pare che il prof ha detto che l'ispezione viene fatta nella fase di progetto dettagliato e codifica...anche perchè se deve verificare il codice statico come lo può fare nella fase di progetto preliminare??

certo che il professore non ha per niente le idee chiare, quindi come può pensare che ce le avremo chiare anche noi al test???

riguardo a questo, oggi qualcuno ha chiesto al prof delucidazioni?

L'ha chiesto un ragazzo (Valefede?!) oggi...
Ha fatto una faccia strana... perché il walkthrough e l'ispection sono modalità di discussione dei documenti del progetto...
Ha detto che giusto per l'ispection si potrebbe dire che è meglio usarlo nella fase di progetto dettagliato ( E NON CODIFICA, manco STATICA!!!!) perché richiede una documentazione un po' più "pesante"...
Ma volendo, si potrebbe usare anche il walkthrough in fase di progetto dettagliato

Insomma, tante domande... molteplici risposte, nessuna sicurezza

theone84 ha scritto:

arale ha scritto:

Il DVT non trova difetti nel software, serve solo ad effettuare la validazione del prodotto..

ok, ma allora quando si parla dei tre aspetti del dvt (component, integration, user testing) perchè sulle dispense c'è scritto che si controlla la presenza di errori? e anche nel caso dell'approccio top down si dice che uno dei vantaggi è quello di verificare i difetti man mano che si procede nel testing, anche nella fase dei requisiti, qual'è il senso?

C'è scritto esplicitamente che il DVT non trova i difetti latenti (è tanto grave che, in questo momento, non colga la sfumatura data da quell'aggettivo?)...

In teoria... un errore non è un difetto... ma può portare ad un difetto....

Rizzi ha scritto:

Rispondo per lo static testing, per il DVT non ho idea.


Per grandi linee direi che in fase di progetto preliminare abbiamo la structure chart, quindi possiamo valutare size, depth, width, edge-to-node-ratio, IF, Y&W (Yin & Winchester). Da qui si deduce che andiamo a valutare metriche relative ai sottoattributi morfologia e information flow dell'attributo modularity. In particolare si verificano anche il numero medio di nodi per livello del diagramma (complessità gerarchica) e il numero medio di chiamate da parte di ogni nodo (complessità strutturale). Dunque abbiamo gli attributi modularity e complexity. Per quanto riguarda gli indici di qualità andrei a controllare quali di quelli che consideriamo vengono impattati (positivamente o negativamente) dagli attributi elencati, e sono Reliability, Flexibility ed Evolubility.

In fase di progetto dettagliato possiamo valutare metriche di qualità quali complessità ciclomatica, depth of nesting, D-Structuredness. Tutte a partire dai flow-graphs dei moduli che fanno parte del nostro prodotto sw. Dunque direi che l'attributo verificato sia la modularity, indici di qualità impattati Flexibility ed Evolubility.


Ditemi se vi quadra....

Riguardo questa domanda mi è capitata tra le mani una molto simile ma in cui vengono citati anche gli attributi, ve la riporto per intero:

Quali indici di qualità e relativi attributi sono verificati nello static testing in fase di progetto preliminare e dettagliato? (Distinguere fra i due casi).

La mia perplessità sta nel fatto che le checklist io le utilizzo a livello di specifica e progetto architetturale, quindi in teoria potrei già ricavare i valori di tutti gli attributi e di conseguenza anche degli indici. So che molto probabilmente sto dicendo una stronzata ma st'esame mi sta rovinando il cervello. Mi levate questo dubbio per favore?

quindi ricapitoliamo:
sia walkthrought che ispezione possono essere fatti a livello di progetto ma non a livello di specifica (per il primo) nè a livello di codice (per il secondo)....

quindi mi chiedo perchè ha detto a lezione (vedi wiki) che l'ispezione può essere fatta o sul documento di progetto o sul codice statico??

per quanto riguarda questa domanda Nello static testing quali indici di qualita sono verificati?e quali in prog. dett. e quali nel prog. prel.?? è stato chiesto qualcosa al prof?

Alt ha scritto:

C'è scritto esplicitamente che il DVT non trova i difetti latenti (è tanto grave che, in questo momento, non colga la sfumatura data da quell'aggettivo?)...

In teoria... un errore non è un difetto... ma può portare ad un difetto....

Grande.. mi hai convinta!