-->

Introduzione alla determinazione di Rich Internet Application

di Daniele Tassone
Pubblicato il 15 Maggio 2003

Identificare il male

Progettare RIA secondo MVC significa limitare la complessità delle applicazioni riducendo i tempi di sviluppo e di manutenzione.

Questo articolo vuole essere solo una mini introduzione alla determinazione dei requisiti per le vostre Rich Internet Application poichè un discussione completa richiederebbe un libro intero dedicato all’argomento.

Con la determinazione dei requisiti imparerete ad evitare uno dei principali motivi per cui le vostre applicazioni potrebbero essere inutili, non gestibili, non aggiornabili, non usabili: in conclusione, un fallimento.

Quando una Rich Internet Application è considerata un fallimento ?

Programmatori, esperti di usability e clienti che commissionano il lavoro daranno quasi sempre una risposta diversa a questa domanda.

• Un programmatore
  dirà che non funziona quando il programma produce un bug ossia un risultato diverso da quello che si voleva ottenere.
• Un esperto di usability
  dirà che non funziona quando la "presentazione" del prodotto non è stata creata correttamente.
• Un cliente
  invece quando i patti presi inizialmente sul progetto sono diversi da quelli ottenuti dal Team di sviluppo.

Volendo generalizzare:
un progetto fallisce quando non porta benefici al cliente.
La tecnologia avanzata non è importante quanto il fornire una soluzione che porta vantaggi concreti a chi la usa.
Una applicazione complessissima in Flash potrebbe essere meno vantaggiosa di un applicazione sempre in Flash ma fatta in dieci minuti.
Un intro animata in Flash, potrebbe essere più vantaggiosa di un’ applicazione in Flash.

Personalmente non considero a priori le “animazioni” in Flash una nullità.

Con questo, non voglio dire che le applicazioni complesse non servono a nulla ,ma semplicemente che l’obiettivo è il vantaggio che l’applicazione porta. Non,quindi, quanto codice scrivete e neppure come lo scrivete.

Mettetevi l’anima in pace, è difficile capire subito che vantaggi deve portare l’applicazione ed è possibile che i vostri clienti vi ostacolino nel capirlo.

La collaborazione con i clienti, risulta fondamentale. E’ importare capire cosa l’applicazione deve fare: a qualsiasi costo.

Sviluppatori e clienti

Il primo passo per produrre delle Rich Internet Application di successo è quello di capire le necessità del cliente.

Non sottovalutate questo aspetto, può rivelarsi un esperienza massacrante :

• clienti confusi su cosa dovrà fare il sistema e cosa la tecnologia offre,
• clienti che non vogliono collaborare con gli sviluppatori ,
• clienti che cambiano troppo frequentemente le proprie idee

sono alcune delle possibili cause che vi ostacolano nel capire cosa e come dovete sviluppare.

Applicare un metodo ed essere razionali, è un buon inizio per determinare i requisiti di una RIA.
Partite da una descrizione sommaria fornita dal cliente, effettuate delle domande per chiarire meglio gli aspetti preliminari del progetto.
Una volta chiariti gli aspetti preliminari, effettuate delle divisioni per “sezioni” su ciò che si è determinato.

Provate a costruire un sommario di progetto raggruppando requisiti che hanno un fine comune.
Aiuta a tenere il filo del discorso tra voi ed il cliente.

Una descrizione sommaria può essere formata da poche righe, come di seguito :

"Abbiamo bisogno di un sito web in cui gli utenti entrato e guardano e/o comprano i nostri prodotti.
Tutti gli utenti possono guardare i prodotti, ma solo gli utenti registrati possono acquistarli.
Per acquistare i prodotti, gli utenti registrati entrano nella pagina “Prodotti”, cliccano su uno dei prodotti disponibili, lo inserisco nel carrello e poi lo pagano."

E’ un buon inizio, ma il vostro compito è quello di catalogare le funzionalità in modo diverso :

1. Utenti registrati e non registrati possono visionare la pagina prodotti
2. Utenti registrati possono inserire un prodotto nel carrello
3. Utenti registrati possono in qualsiasi momento della navigazione acquistare il contenuto del carrello

O meglio ancora, associando anche una o più lettere :

1prodotti. Utenti registrati e non registrati possono visionare la pagina prodotti
2prodotti. Utenti registrati possono inserire un prodotto nel carrello
3prodotti. Utenti registrati possono in qualsiasi momento della navigazione acquistare il contenuto del carrello

Ad ogni “funzionalità” del sistema associate un codice univoco formato da numero+parola.

In questo modo potete tenere traccia dei bug e/o cambiamenti del sistema sapendo quali requisiti verranno influenzati.

Linguaggi visuali

Provate a cercare la vostra città su un atlante, ci metterete meno di qualche minuto:
individuate il continente, poi individuate la nazione, poi individuate la città: fine.

Ora pensate che l’atlante non sia disponibile, ma in compenso avete a disposizione un elenco di tutte le città del mondo divise per posizione latitudine e longitudine :

lat0Lon0 citta1 stato1
lat0Lon1 citta2 stato1
lat8Lon2 citta2 stato1
..
..
lat40Lon32 citta142 stato31
lat40Lon33 citta142 stato12

molto probabilmente ci metterete diversi minuti in più oltre a ritrovarvi l’indice consumato già a metà ricerca.

Bene, anche per catalogare i requisiti delle RIA si ricorre ad un metodo analogo: provate a modellare i requisiti tramite un linguaggio visuale, oltre a scriverli su foglio in modo informale. Aiuta la comprensione sia vostra che dei clienti.

Il consiglio che posso dare, è catalogare e modellare i requisiti in ogni progetto. Non importa quale linguaggio visuale usate: UML, applicazioni RAD o disegni a mano libera.
Fatelo.

Nella mia esperienza di sviluppo su RIA, ho notato che molte persone prima di leggere il documento
dei requisiti guardassero la presentazione “grafica” del progetto.

Flash vi aiuta enormemente nello sviluppo RAD, quindi è pensabile sviluppare un prototipo in 10 minuti
direttamente in sede dal cliente.

I linguaggi visuali sono importanti, ma non risolvono tutti i problemi.

Avete ancora bisogno di catalogare i requisiti numerandoli: una bozza grafica non vi mostrera’ mai i requisiti di sicurezza, finirete per perderli se non li catalogate.

Purtroppo non esiste ancora un metodo “copia/incolla” per determinare i requisiti.

Anche se ci sono tutti i nostri cari metodi per condurre un’applicazione verso il successo, non è possibile pensare con un processo di determinazione dei requisiti sia sempre giusto e neppure che una sola persona riesca a determinare tutti i requisiti (funzionalità, usability, immagine aziendale, integrazione)

Ma il cuore di una RIA come di qualsiasi altro progetto è questo :
se non capite esattamente il cliente cosa vuole, non potete sviluppare una soluzione efficiente.

Dovete impegnarvi a capire la maggior parte del progetto in questa fase.
Cancellare un requisito e scriverlo in questa fase vi costa vi costa 3 passaggi :

• prendere la gomma
• cancellare il requsito scritto
• riscriverlo nel modo giusto

Ossia, se avevate :

1. Utenti registrati e non registrati possono visionare la pagina prodotti
2. Utenti registrati possono inserire un prodotto nel carrello
3. Utenti registrati possono in qualsiasi momento della navigazione acquistare il contenuto del carrello

Lo cambierete in :

1. Solo gli utenti registrati possono visionare la pagina prodotti
2. Utenti registrati possono inserire un prodotto nel carrello
3. Utenti registrati possono in qualsiasi momento della navigazione acquistare il contenuto del carrello

Cambiare un requisito in fase di implementazione, potrebbe richiedervi diversi giorni e nella peggiore delle ipotesi cancellare l’intero progetto e rifarlo da capo.

Una RIA è un progetto molto vasto, avete bisogno come il pane di questa fase.
Non c’è altro da aggiungere.

Documento dei requisiti

Un documento dei requisiti, è un documento scritto con e per il cliente.
Utilizzate un linguaggio informale poiché un linguaggio troppo tecnico potrebbe confondere il cliente.

E’ il vostro primo risultato, è la colonna portante di un progetto.
In qualità di sviluppatori, posso dire che è la vostra unica arma contro i programmatori che implementano il progetto.

Un programmatore deve scrivere solo il codice che basta per garantire che il documento dei requisiti sia rispettato.
Altre implementazioni devono essere valutate sia in termini di tempo che di costi.

Che il vostro programma di spedizione e-mail funzioni con tutti gli SMTP del mondo
quando il documento dei requisiti dichiarava che il programma finito avrebbe spedito email solo dall’SMTP dell’azienda cliente e per questa compatibilità che non vi è stata richiesta avete sacrificato 2 giorni di lavoro sulla tabella di marcia:
cari programmatori, prima di dirlo al vostro capo aspettate il giorno in cui vi saluti per andare in luna di miele.

In qualità di sviluppatori è anche la vostra arma contro clienti senza scrupoli:
un noto proverbio recita “patti chiari ed amicizia lunga”, siate certosini del determinare le funzionalità ed i vostri clienti apprezzeranno anche la vostra trasparenza e serietà.

Conclusioni

Determinare i requisiti di una Rich Internet Application è fondamentale quanto svilupparla e farla funzionare.
Capire il cliente significa capire i problemi ed il progetto.

Raggruppate i requisiti secondo il loro scopo, vi aiuta a definire in che zona il progetto si espande.
Usate un linguaggio visuale (non importa quale) per chiarire i requisiti e per dare una vista diversa al progetto
da consultare in parallelo alla lista dei requisiti.

Catalogate i requisiti della vostra Rich Internet Application e fate in modo che i programmatori implementino non ciò che la loro testa vorrebbe scrivere, ma ciò che il documento dei requisiti impone.

Siate i “notai” del progetto ,siate precisi nel capire il cliente: egli apprezzerà la vostra trasparenza.

Allineate gli sviluppatori con il progetto al fine che implementino ciò che viene richiesto dal documento dei requisiti.

Determinare correttamente i requisiti significa mettere il primo mattone per il disegno del database e per la creazione di applicazioni secondo MVC. Progettare RIA secondo MVC significa limitare la complessità delle applicazioni riducendo i tempi di sviluppo e di manutenzione. Benefici non trascurabili.

Capire il cliente significa dire essere un passo avanti per la creazione di Rich Internet Application di puro successo.