[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux_var] R: Re: Testo per scrittura specifiche tecniche



>Da: luca-mastro@libero.it
>Data: 30/12/2013 0.01

>Le linee guida potrebbero essere orientate verso la definizione e la
>semplificazione dei diagrammi ER (casi particolari di diagrammi UML).

[...]

>Un altro approccio potrebbe essere servirsi di Use Case Models che,
>attraverso appositi diagrammi UML stabiliscono sia i gradi di libertà

[...]

>Il fatto che l'applicativo abbia dei bachi ti potrebbe consentire di
>'costruire' un workflow delle azioni fra utente e applicazione, cosa

Ciao Luca,
anche io avevo pensato di affrontare alla tua stessa maniera il problema:
-Analisi della struttura dei dati;
-Analisi delle funzioni usate dagli utenti;
-Ricostruzione della "business logic" dell'applicazione.
Poi però mettere in pratica tale teoria è un altro paio di maniche. Ad
esempio, la struttura dei dati. Al di là del numero assurdo di tabelle
usate, ad un certo punto mi trovo di fronte al campo spese_altre.
Il nome del campo sembrerebbe auto-esplicativo, ma qualcosa non
torna. Toccandolo si ottengono risultati imprevisti. Così dopo una
settimana di mal di testa scopro da un utente che lavora in azienda
da anni che in realtà in spese_altre sono contenute... le spese di
trasporto: il motivo di questa scelta è perso nella nebbia del tempo.
A questo punto mi sono chiesto: non sarò il primo al mondo che si
trova a dover maneggiare un'applicazione legacy, come si è
comportato chi ha avuto in passato questo problema?
Saluti,
Giorgio

_______________________________________________
Talking mailing list
Talking@ml.linuxvar.it
http://ml.linuxvar.it/cgi-bin/mailman/listinfo/talking