Guarda, per quello che può contare, risponderei come te... Direi che durante il testing statico è possibile verificare tutti gli indici di qualità, mediante le checklist degli attributi ... affidabilità compresa.

Non saprei..

..secondo me quel "modularity" biascicato un qualche senso ce l'ha..

..visto che sulle dispense c'è pure scritto che morphology e information flow sono attributi di modularity..

..aggiungendo il fatto che oggi, quando gli ho chiesto del flow graph mi ha risposto:
"E' un metodo di rappresentazione attraverso il quale puoi calcolare morphology e information flow, sottoattributi di modularity"..

..e considerato il suo spassionato amore per la modularity...

..io sarei portata a dire MODULARITY!

E infatti verifichi la modularity con le checklist
Ma credo sia un po' riduttivo dire solo modularità.. in fondo, anche solo prendendo in considerazione l'information flow, ti vien da pensare anche alla complessità...
Però, per ogni checklist, hai un attributo da verificare... tutti quei 10 che, con diverse combinazioni, vanno a far parte degli indici di qualità...

Rimarrebbe ancora in sospeso la questione "indice"... ma la modularità è un attributo (con i ben noti sottoattributi)... ma lui chiede anche l'indice... e modularity è tra i più diffusi negli indici di qualità... insieme a complessità e tracciabilità...

Nel progetto preliminare morphology e information flow!

Mah.. più penso a questa domanda, più mi vengono dei dubbi!

Nel progetto preliminare morphology e information flow!

ok come diceva Rizzi...

ricapitoliamo anche qui:

progetto preliminare: 1)sottoattributi morphology e information flow --> attributo modularity

2) attributo complexity ( compl. strutturale e gerarchica)

===> indici reliability, flexibility e evolubility.

Ragazzi, purtroppo con quello che abbiamo a disposizione e la non collaborazione del prof difficile tirar fuori una risposta esatta alla ormai famosa domanda sullo static testing. Ognuno si faccia la sua idea e risponda senza farsi condizionare troppo dagli altri....almeno se si sbaglia si sbaglia da soli...

Se questo esame fosse orale lo passerei con 30 e lode... così spero in un 18 :cry:

La verifica di un prodotto SW consiste nel confrontare per ogni fase del processo di sviluppo la consistenza dell'input con la consistenza dell'output. Verificare un prodotto vuol dire accertare che sia conforme a tutti gli indici di qualità.

La validazione consiste nel confronto del prodotto finale con gli user needs, per garantire che il SW sia conforme alle richieste dei clienti.


Il tutto preso dal pighin, è giusto o butto definitivamente il pighin?

La verifica di un prodotto SW consiste nel confrontare per ogni fase del processo di sviluppo la consistenza dell'input con la consistenza dell'output. Verificare un prodotto vuol dire accertare che sia conforme a tutti gli indici di qualità.

La validazione consiste nel confronto del prodotto finale con gli user needs, per garantire che il SW sia conforme alle richieste dei clienti.


Il tutto preso dal pighin, è giusto o butto definitivamente il pighin?

giusto.
verifica risponde alla domanda : sto sviluppando il prodotto software correttamente?

validazione risponde alla domanda : sto sviluppando il prodotto software corretto?

La verifica di un prodotto SW consiste nel confrontare per ogni fase del processo di sviluppo la consistenza dell'input con la consistenza dell'output. Verificare un prodotto vuol dire accertare che sia conforme a tutti gli indici di qualità.

La validazione consiste nel confronto del prodotto finale con gli user needs, per garantire che il SW sia conforme alle richieste dei clienti.


Il tutto preso dal pighin, è giusto o butto definitivamente il pighin?

Leggendo, sembrerebbe giusto..
Aggiungo che la verifica controlla la conformità del software system alle sue specifiche... (dal Tian, software quality engineering)...
E la validazione la conformità ai requisiti utente (Es. che ci siano tutte le funzioni che il cliente ha richiesto)...

Sto andando in paranoia... ma cerco di convincermi che, con queste dispense, son passati dei ragazzi, lo scorso anno...

Comunque le modalità su come "fare" inspection e walkthrough sono diverse dal libro a quello che è stato detto in aula.

Comunque le modalità su come "fare" inspection e walkthrough sono diverse dal libro a quello che è stato detto in aula.

in cosa?

Nel progetto preliminare morphology e information flow!

ok come diceva Rizzi...

ricapitoliamo anche qui:

progetto preliminare: 1)sottoattributi morphology e information flow --> attributo modularity

2) attributo complexity ( compl. strutturale e gerarchica)

===> indici reliability, flexibility e evolubility.

Sta domanda ci sta facendo uscire pazzi...qualche pagina fa anche ALT aveva azzardato una risposta...
Comunque sia sono d'accordo con questo ultimo schema...

Allora come la spiegate questa?

Sullo schach tra i documenti su cui si fa inspection c'è anche il codice, il prof ha detto che non si applica alla fase di codifica ma ci si ferma al prog.dettagliato.

Di bene in meglio...

E ora la domanda della vita...
Ma nel progetto dettagliato?

Sul libro non dice niente circa il compilare la checklist durante lo svolgimento.
Parla di una checklist ma è quella realtiva agli errori trovati in progetti passati e non centra niente con quella da compilare per misurare gli attributi.

Inspection:
nella fase preparation non vengono stilati i report ma vengono distribuiti una lista di errori con le relative frequenze di progetti passati in modo da concentrarsi su quelli.

in entrambi i guasti trovati non vengono mai corretti dal team che sta facendo queto test solo commentati. Saranno i responsabili della fase in esame a correggerli.

WT dovrebbe durare 2 ore, Inspection moooolto di più.

Ricapitolando nella follia :
1)Abbiamo un professore che tutto fa forchè aiutarci nel riuscire a passare un esame e ha la grande capacità di confondere le idee a chiunque...
2)Abbiamo il Pighin che,a quanto pare, dice un sacco di m.i.n.c.h.i.a.t.e
3)Due libri di testo che dicono cose diverse.
4)Domande di esame sbagliate...
5)I grafi che non si sa mai come rappresentarli...
6)Un professore che corregge i compiti...sappiamo come...

Allegria......

Ricapitolando nella follia :
1)Abbiamo un professore che tutto fa forchè aiutarci nel riuscire a passare un esame e ha la grande capacità di confondere le idee a chiunque...
2)Abbiamo il Pighin che,a quanto pare, dice un sacco di m.i.n.c.h.i.a.t.e
3)Due libri di testo che dicono cose diverse.
4)Domande di esame sbagliate...
5)I grafi che non si sa mai come rappresentarli...
6)Un professore che corregge i compiti...sappiamo come...

Allegria......

ZAAAAAZUEEEEEELAAAA---- ZAAAAAZUEEEEEEELAAAA---- a e i o u... y...

Dai, mica possiamo addossare tutte le colpe a Pighin... quel santo ragazzo c'ha dato un punto di partenza... che poi ci siano delle imprecisioni... per forza, sono appunti...

Ricapitolando nella follia :
1)Abbiamo un professore che tutto fa forchè aiutarci nel riuscire a passare un esame e ha la grande capacità di confondere le idee a chiunque...
2)Abbiamo il Pighin che,a quanto pare, dice un sacco di m.i.n.c.h.i.a.t.e
3)Due libri di testo che dicono cose diverse.
4)Domande di esame sbagliate...
5)I grafi che non si sa mai come rappresentarli...
6)Un professore che corregge i compiti...sappiamo come...

Allegria......

ZAAAAAZUEEEEEELAAAA---- ZAAAAAZUEEEEEEELAAAA---- a e i o u... y...

Dai, mica possiamo addossare tutte le colpe a Pighin... quel santo ragazzo c'ha dato un punto di partenza... che poi ci siano delle imprecisioni... per forza, sono appunti...

Io al posto di zazzuela metterei : CACCETEGMA
Ma io non me la prendo con Pighin,che meno male che c'è...me la prendo più in altro...con un certo professore.......

Sul libro non dice niente circa il compilare la checklist durante lo svolgimento.
Parla di una checklist ma è quella realtiva agli errori trovati in progetti passati e non centra niente con quella da compilare per misurare gli attributi.

Inspection:
nella fase preparation non vengono stilati i report ma vengono distribuiti una lista di errori con le relative frequenze di progetti passati in modo da concentrarsi su quelli.

in entrambi i guasti trovati non vengono mai corretti dal team che sta facendo queto test solo commentati. Saranno i responsabili della fase in esame a correggerli.

WT dovrebbe durare 2 ore, Inspection moooolto di più.

'Sta cosa delle checklist m'ha fatto tribolare parecchio... perché non trovo riferimenti in libri su quello che ha fatto lui...

Da quello che leggo dai tuoi appunti (il file .doc che hai reso disponibile per un po')... ho dedotto, sulle checklist, che:
- Coprono tutti gli attributi (e vabbé..)
- La somma dei valori degli attributi ottenuti, combinati in una certa maniera, mi danno i valori degli indici (ok, fin qui..)
- Si effettuano in fase di progetto preliminare (ne parla introducendo coupling, coesion, morfologia e information flow) a proposito della structure chart (ma su questo non ho certezza, perché c'è scritto "suddetta struttura", dopo aver parlato anche di flowgraph)
- fanno parte del testing statico.

Chi offre di più??

e in fase di specifica (come dimostra una figura che ricapitola i vari tipi di testing a cosa sono applicati)[/size][/b]
- fanno parte del testing statico.

Chi offre di più??