|
analisi-disegno.com Homepage | Notiziario | In English |
analisi-disegno.news - 15 ottobre 2008Documentare l'architettura softwareL'architettura di un sistema software ci dice come è fatto il sistema:
Mentre si sviluppa, condividere l'architettura agevola la comunicazione tra i partecipanti al progetto, soprattutto quando le persone operano in luoghi diversi, o quando intervengono nel progetto in momenti successivi, o quando si collabora tra entità diverse, in un rapporto cliente - fornitore. Per un sistema già esistente, se non abbiamo altre fonti disponibili, l'architettura software è rilevabile dal codice. Ma è necessaria molta fatica per scoprirla. Meglio avere una qualche forma di documentazione. Una buona documentazione architetturale permette di capire un’applicazione esistente più in fretta; e ciò vale sia quando dobbiamo studiare un’applicazione realizzata da altri, sia quando dobbiamo rimettere le mani su una che abbiamo realizzato noi stessi in passato. Quali sono le caratteristiche di una "buona" documentazione architetturale? La sintesi, la chiarezza e l'aggiornamento. La sintesiL'architettura va rappresentata nel modo più semplice ed essenziale. Con pochi diagrammi e con descrizioni testuali stringate. La rappresentazione dell'architettura deve fornire una visione di insieme del sistema, della sua struttura, delle interazioni tra le sue parti. Senza dettagli, se non per zoomare su aspetti particolari che è necessario evidenziare a chi dovrà prendere in carico il sistema. Più la documentazione dell'architettura è dettagliata, più diventa difficile che sia chiara ed aggiornata. Meglio che sia sintetica. La chiarezzaQuando documentiamo, il nostro obiettivo deve essere quello di comunicare efficacemente. Per fortuna esiste una notazione standard - UML, lo Unified Modeling Language - per rappresentare le architetture software. Ma bisogna usarla bene. Quando si schizza un diagramma per ragionare su un problema, la nostra attenzione è concentrata sul problema, non sul diagramma. Quando si documenta, invece, dobbiamo fare tutto ciò che si può per farci capire. Ciò significa, ad esempio, creare diagrammi leggibili; evitare l'uso di costrutti UML poco comuni, noti solo agli esperti; non cercare di esplicitare tutto in forma grafica: se è vero che un'immagine vale mille parole, qualche parola di commento associata alle immagini può semplificare diagrammi che altrimenti risulterebbero troppo sofisticati e complessi. L'aggiornamentoIn parecchie organizzazioni, è raro trovare documentazione aggiornata. Ma l'invecchiamento (della documentazione) può essere ritardato o evitato. Quando i documenti architetturali sono sintetici, è più difficile che vengano resi obsoleti da modifiche marginali al sistema. E se la documentazione architetturale viene consolidata quando si è completata la nuova versione del sistema, just-in-time, il disallineamento non ha ragione di esistere. Aggiornare la documentazione dell’architettura software può non essere troppo oneroso, se si segue un approccio minimalista, documentando solo le scelte fondamentali, senza scendere in dettaglio su ogni aspetto della progettazione. **************************************************************** Segnalazioni*** I requisiti si scoprono meglio dopo ***************** La situazione ideale, si sa, è quella in cui i requisiti vengono chiariti all'inizio di un progetto. Ma per quanto ci sforziamo di riuscirci, e anche se ci avvaliamo delle tecniche più efficaci per farlo, sappiamo che spesso non è possibile. Esprimere requisiti per un sistema che esiste già è molto più facile che esprimerli per uno che non esiste ancora. Vedi il sistema, lo usi, capisci quello che non funziona, quello che manca, quello che si potrebbe, vorrebbe, dovrebbe migliorare. Molto più facile che rispondere a domande su come si vorrà qualcosa che non esiste ancora, o sulla correttezza di un modello, o di una specifica. È un assunto di semplice buon senso. Naturalmente, bisogna vedere come trarne le conseguenze in un contesto di sviluppo professionale, con relazioni cliente-fornitore, contratti, ecc. Su questo, un articolo interessante di Martin Fowler.
*** Precisare i requisiti ******************************* Un intervento di Tom Gilb su Requirements Network: "Requirements Relationships: A Theory, some Principles, and a Practical Approach" Tom Gilb è uno dei padri dell'approccio iterativo e incrementale, con il metodo Evo (1988). Per quanto riguarda la gestione dei requisiti, il suo contributo fondamentale è stato l'introduzione di Planguage, un linguaggio per precisare i requisiti. Requirements Network è un sito che pubblica settimanalmente articoli sulla gestione requisiti. Bisogna registrarsi con user e password per accedere, scaricare articoli, commentare, intervenire.
*** MoSCoW e priorità *********************************** Il primo corso a cui partecipai sull'analisi dei sistemi - parecchi anni fa - insegnava ad usare per i requisiti una classificazione MoSCoW. MoSCoW è un acronimo che sta per:
Non ho mai usato la classificazione MoSCoW, anche se suggestiva. E non l'ho mai insegnata nei miei corsi. Ho sempre usato la tecnica di classificare i requisiti in termini di priorità, che ritenevo più efficace. Ma non avevo ragionato a fondo sulla classificazione MoSCoW. L'ha fatto invece James Shore.
*** Story Maps ****************************************** Rappresentare le funzionalità di un sistema in un modo comprensibile sia agli stakeholders che agli sviluppatori. E inoltre utile per indicare le priorità. La tecnica delle "story maps" è semplice. Jeff Patton la descrive in questo intervento.
*** Software perfetto ************************* "Perfect Software and other illusions about testing". È un libro di Gerald Weinberg, uscito da poco. Tra tutte le attività collegate al software, il testing è l'attività più fraintesa. Anche dai professionisti dello sviluppo. Il libriccino è sottile, scritto bene, si legge in fretta, non entra in dettagli tecnici. Un'ottima introduzione alla realtà del testing, per chiunque lavori in un progetto, per i manager, per i committenti. Anche per chi di software sa poco o nulla. ******************************************************************** Se volete, potete contribuire ad ANALISI-DISEGNO:
******************************************************************** ANALISI-DISEGNO - (c) Adriano Comai ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita. ******************************************************************** Archivio notiziari | Notiziario precedente | Notiziario successivo |
analisi-disegno.com, servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.