il lungo percorso dall'analisi all'implementazione

moved

parto a bomba con una domanda:

come affrontate un nuovo progetto?

Se vi viene chiesto di sviluppare un’applicazione web, per esempio, come vi regolate?

Una volta definita l’analisi, quando si tratta di modellarla, usate UML? Usate degli strumenti di disegno (dia?) o dei gran fogli di carta? poi passate al db ed infine al nosto yii? oppure, come a volte capita di fare a me, realizzate piccoli pezzettini db-interfaccia che poi allargate piano piano con altre funzionalità?

Si lo so sono curioso, ma altrimenti a che servono i forum <wink>

Io di solito faccio tutto su un foglio.

Prima lascio parlare il cliente a vanvera 10 minuti, mezz’ora, dipende da quanto ci mette a far pace col cervello.

Poi si comincia l’analisi. Il trucco e’ farsi spiegare un po’ di cosa ha bisogno, e poi incastrarlo con domande tipo che lo costringano a pensare, di solito vanno benissimo le domande sulle cardinalita’.

Tipo: ma un progetto ha una commessa o piu’ commesse?

Questo tipo di domande obbliga il cliente a ragionare e questo giova molto alla progettazione.

Su un foglio mi scrivo quanto di sensato si resce a raccogliere, di solito in un formato molto simile al diagramma ER del database (solo perche’ mi aiuta a ragionare, la forma non e’ importante).

Un altro punto fondamentale nei progetti e’ riuscire ad isolare una piccola parte completa e coerente. Di solito il cliente vuole un razzo per andare sulla luna, ma e’ facile convincerlo a partire con una bicicletta “che tanto poi facciamo due upgrade…”.

Di solito non faccio mai documenti di progetto, se si riesce a partire da un qualcosa di piccolo da espandere poi, io vado direttamente al prototipo. Scritto il prototipo (e pagato) si va di upgrade, ma ormai e’ fatta: il cliente a questo punto ha qualcosa in mano con cui giocare e sa spiegare con molta precisione cosa gli serve in piu’, diventa un attore attivo della progettazione.

Io di solito parto dai casi d’uso, ma non dettaglio molto: faccio schizzi generici ed a volte separati.

I casi d’uso li accompagno da qualche diagramma delle attività. Più che altro scrivo pezzi di diagramma, quasi mai tutto insieme. Scrivo piccole porzioni di codice … se non riesco a risolvere un problema, faccio uso di UML.

Non uso quasi mai i diagrammi delle classi, ma quando serve faccio uso dei CRC. Sono dei diagrammi adorabili e davvero comodi.

Ultimo ma non meno importante: tecnica del pomodoro (quando serve) e sviluppo agile. Piccoli avanzamenti e confronti costanti con il cliente per definire piano piano le milestone e ridurre al minimo gli errori e le incomprensioni. Quasi mai email: meglio fare una bella telefonata.

Per i più temerari ci sono i tests =).

Non faccio mai tutte queste cose insieme nello stesso lavoro. Spesso parto a bomba (ndr) e faccio piccoli pezzetti di codice con piccoli obiettivi … Ma cerco sempre e comunque di crearmi una mia personale documentazione che non riguarda quasi mai il progetto ma le tecniche usate per programmarlo.

Per esempio ora sto facendo una gestione delle commesse per l’azienda dove lavoro dove in UML ho realizzato solo i casi d’uso. Per un altro cliente solo il diagramma delle attività. Per un altro solo user stories.

In sintesi: dipende =). Per fare lo scarico tempi mi sono messo ad intervistare presidente,commerciale,segretaria,capoprogettio … ho fatto i miei bei disegnini … e poi ho preso Yii e li ho stupiti =).

Per un altro cliente sono stato ancora più fortunato: facciamo tante chiacchiere al telefono e loro mi inviano subito dopo un bel documento word. Inconsciamente mi inviano le user stories che poi uso per creare il loro sito web.