Io nelle somiglianza aggiungerei Cini di ricerca operativa con Nino manfredi.....questa è clamorosa persino l'audio è lo stesso...e qua chiudo la parentesi ludica nella discussione che di divertente sta materia forse c'a solo le lezioni con Calamaro :shock: Spero che la LoMartire non interroghi quest anno!!!

Te prego, nun la nominà nemmeno...

Per tornare IT, quante stakeholder requests vi sono venute? E le features?

A noi sono circa 40 stakeholder requests! però non siamo sicuri se diminuirle. Per quanto riguarda le features, ancora non abbiamo ci abbiamo pensato perchè stiamo facendo prima i casi d'uso.

Per quanto riguarda le features, ancora non abbiamo ci abbiamo pensato perchè stiamo facendo prima i casi d'uso.

Ho parlato con più di un gruppo che sta facendo così: io non ho capito questa cosa sinceramente (non sto dicendo che state sbagliando eh, ma non mi torna qualcosa): prima leggi le stakeholder request per ricavare i needs (quindi sei nel dominio del problema); poi fai il modello dei casi d'uso (quindi ti sposti nel dominio della soluzione: stai dicendo come il sistema fa quello che deve fare, anche se ad alto livello); e poi ricavi le features (tornando nel dominio del problema). Inoltre i casi d'uso mappano le features: ok, la tracciabilità la ottieni comunque, ma non è così naturale secondo me.

E' legittimo fare così? :roll: Calavaro si è espresso?

E' legittimo fare così? :roll: Calavaro si è espresso?

Calavaro ha detto che si può fare in entrambi i modi, l'importante è tracciare needs-features-use cases. Ha detto solo che secondo lui è più comodo fare un'analisi in ampiezza piuttosto che in profondità.

io ho usato un approccio misto.. nel senso che ho fatto nell'ordine:
1-glossario
2-stak. req (needs)
3-UC diagrams
4-features
5-UC spec (requirements)
ciao

io ho usato un approccio misto.. nel senso che ho fatto nell'ordine:
1-glossario
2-stak. req (needs)
3-UC diagrams
4-features
5-UC spec (requirements)
ciao

Anche noi stiamo seguendo questo approccio! però abbiamo dei problemi con le features! Potresti fare un esempio di come hai mappato una need in una feature? Non vi sembra troppo tecnico il documento che ci ha fornito Calavaro?

guarda stavo proprio per scrivere sul forum per chiedere qualcosa di analogo..
ad es noi abbiamo:
STRQ3 Ogni fondo è suddiviso nelle seguenti voci di spesa:
STRQ3.1• Materiale di consumo
STRQ3.2• Materiale inventariabile
STRQ3.3• Spese di personale (borse di studio o retribuzioni per contratti a tempo determinato)
STRQ3.4• Missioni (viaggi e congressi)
STRQ3.5• Varie
STRQ3.6• Trattenute (quanto dovuto al dipartimento per l’hosting della ricerca).

Il problema è che io avevo scritto una feature cosi:
FEAT3 Il sistema caratterizza un fondo mediante le seguenti voci di spesa: Materiale di consumo, Materiale inventariabile, Spese per il personale, Missioni (Viaggi e congressi), Varie, Trattenute.

Stavo pensando pero' che sarebbe + corretto spezzettarla in una feat per ogni campo. Qualcosa del tipo:
FEAT3 Il sistema registra, per un fondo, la seguente voce di spesa: Mat, di consumo.
FEAT4 Il sistema registra, per un fondo, la seguente voce di spesa: Mat. inventatiabile
ecc

In questo modo mappi una STRQ su ogni feature e se un domani cambia la need (ad esempio non bisogna piu' registrare la voce varie) trovi subito la feat abbinata...
Che ne pensate di questo ragionamento?
In questo modo hai poi che praticamente ogni STRQ3.i su una feat.
Che ne

Smoking, ma facendo come hai detto non vedo più la differenza tra needs e feqtures... Cioè, possibile che c'è solo un verbo di differenza?

Nel mio gruppo abbiamo visto le needs come molto generiche; ad esempio, quando parla di tutte le caratteristiche del fondo tipo nome, eccetera come need abbiamo messo "Il sistema deve caratterizzare in modo univoco il fondo" e come features tutti i vari "campi" utili per la caratterizzazione.

Intendiamoci, manco così quadra molto, però mi sembra che abbia più "senso"...

ma quella divisione in strq 3.i l'aveva fatta lui a lezione.. poi sul forum ha detto che le strq possono anche essere generiche. quindi in teoria ogni procedimento è giusto, l'importante (credo, visto che non ci sono cose sicure in questo campo) è avere delle features al giusto livello di astrazione (non torppo dettagliate, ma neanche avere un'unica feature!)..
Altra cosa, a lezione ha detto di lasciare il file doc, ossia le needs, quanto piu' possibile inalterato per evitare di travisare quello che vogliono i clienti...

ma solo io c'ho l'impressione che sta materia è un po casa delle libertà, facciamo un po come ca**o ci pare?

alla fine si..

scusate ma per voi sono features o suppl requirements affermazioni del tipo "Il sistema impedisce di registrare spese se non ci sono i soldi disponibili nella relativa voce di spesa"? Sarebbe un requisito funzionale giusto? non mappa su nessuna user need ma è importante metterla..

Esiste un modello per il documento di Use Case Model Survey??

Il prof. ha detto qualcosa in merito?

Stavo pensando pero' che sarebbe + corretto spezzettarla in una feat per ogni campo. Qualcosa del tipo:
FEAT3 Il sistema registra, per un fondo, la seguente voce di spesa: Mat, di consumo.
FEAT4 Il sistema registra, per un fondo, la seguente voce di spesa: Mat. inventatiabile
ecc

In questo modo mappi una STRQ su ogni feature e se un domani cambia la need (ad esempio non bisogna piu' registrare la voce varie) trovi subito la feat abbinata...
Che ne pensate di questo ragionamento?

Smoking, ma facendo come hai detto non vedo più la differenza tra needs e feqtures... Cioè, possibile che c'è solo un verbo di differenza?

Nel mio gruppo abbiamo visto le needs come molto generiche; ad esempio, quando parla di tutte le caratteristiche del fondo tipo nome, eccetera come need abbiamo messo "Il sistema deve caratterizzare in modo univoco il fondo" e come features tutti i vari "campi" utili per la caratterizzazione.

Intendiamoci, manco così quadra molto, però mi sembra che abbia più "senso"...

@Smoking: non sono d'accordo sul mappare STRQ e FEAT in rapporto 1:1. A quel punto perde di senso individuare le features. L'obiettivo secondo me è (fra le altre cose) passare da (numeri a caso) 100 STRQ a 30 FEAT a 15 UC. E' vero che lui ha fatto quella divisione nelle STRQ, ma non è detto che questa debba ripercuotersi nelle FEAT.

@Darkside: mettere una feature per ogni "campo" utile per la caratterizzazione mi pare eccessivo: quelli alla fine saranno campi di una relazione nel DB, e/o attributi di una classe. Considerarli come features separate sarebbe comodo nel caso in cui queste possano poi essere mappate da casi d'uso diversi, ma in questo caso non mi viene in mente come sia possibile.

@Smoking && Darkside: una feature è "qualcosa" che fa il sistema, mentre quei "campi" descrivono molto ad alto livello parte del modello dei dati.

Tutto rigorosamente IMHO.

scusate ma per voi sono features o suppl requirements affermazioni del tipo "Il sistema impedisce di registrare spese se non ci sono i soldi disponibili nella relativa voce di spesa"? Sarebbe un requisito funzionale giusto? non mappa su nessuna user need ma è importante metterla..

Secondo me è più giusto metterlo nel caso d'uso appropriato. C'è quel "se" che mi chiama alla mente proprio un flusso alternativo :P .

@Smoking && Darkside: una feature è "qualcosa" che fa il sistema, mentre quei "campi" descrivono molto ad alto livello parte del modello dei dati.

Tutto rigorosamente IMHO.

perfettamente d'accordo, mi sono espresso male prima.. cioè pensavo qualcosa del tipo:

-STRQ: il sistema deve caratterizzare univocamente il fondo
-FEAT: il sistema identifica ogni fondo mediante un nome, un totale, bla bla
-Implementazione: un sistema con tutti i campi

Rimane sempre da capì che differenza c'è tra need e feature...

STRQ - User need: "1: voglio che quando clicco sul nome di un campo la tabella relativa ai 'prestiti a strozzo' si riordina rispetto a quella colonna, sia a aumentà che no... capito, no?. 2: ogni prestito ha le seguenti voci [...]. si me pare che so tutte, tanto al massimo le aggiungi dopo, che ce vole.
3: ah poi, si può fare che c'è una spranga sul bottone 'nuovo prestito'?"

Feature: "1: il sistema permette di visualizzare i record relativi ai 'prestiti a strozzo' in ordine crescente/decrescente rispetto a una qualsiasi delle colonne, nella fattispecie 'ammontare', 'interessi', 'numero fratture inflitte', cliccando sulla colonna interessata."

a) Chiaramente la 3 è un need, ma non è una feature del sistema.
b) Le feature sono un po' più formali, scritte meglio e un po' meno ad alto livello, anche se restano nel dominio del problema.
c) Le feature le scrivo io, le STRQ il cliente
d) (banale ma fondamentale) Le feature sono direttamente tracciate agli UC

Di sicuro ce ne sono altre, appena mi vengono le scrivo.

ragazzi scusate ,
mi è giunta allorecchio una possibile "diceria"...

vi risulta che la consegna del progetto è posticipata di qualche giorno?
lo ha detto lui?

se sapete qualcosa...

grazie