Informatica Industriale

Smoking_Man ha scritto:

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..