analisi-disegno.com

"Large Scale Agile" è il titolo del numero monografico di maggio / giugno 2013 di CrossTalk, la rivista sullo sviluppo software delle forze armate USA.
Articoli su come sviluppare in modo agile per progetti di grandi dimensioni e distribuiti in più centri; su come coniugare solidità architetturale e pratiche agili; sulle pratiche di stima di dimensioni e di impegno.

Un articolo del settimanale inglese The Observer cita alcuni casi famosi in cui progetti informatici di grandi dimensioni hanno portato a rischi ingestibili e a fallimenti.

A scopo preventivo, l'articolo raccomanda di rendere obbligatoria per i manager IT la lettura del classico "The Mythical Man-Month" (il mitico mese-uomo), libro di Fred Brooks pubblicato nel 1975 dopo che Brooks aveva guidato il complesso progetto di sviluppo del sistema operativo IBM OS/360.

"The Mythical Man-Month" è in effetti un testo ricco di insegnamenti utili, tra cui il fatto che aggiungere ulteriori sviluppatori ad un progetto in ritardo provoca ritardi ulteriori. Per la sua utilità, nota l'autore dell'articolo di The Observer, il libro di Brooks continua ad essere pubblicato regolarmente dal 1975 ad oggi. Purtroppo, come accade per diversi altri testi fondamentali dell'IT (e non solo), non è mai stato tradotto in italiano.

Parlare di architettura software ha senso solo quando si tratta di capire il livello di servizio richiesto e dare risposte misurabili ai requisiti. Tutto il resto è fuffa, sostiene Tom Gilb in questo video.

Come conviene nominare le funzioni, come conviene nominare i test?

Secondo Kent Beck ci sono buone ragioni per preferire nomi corti (ma non troppo) per le funzioni, nomi più lunghi per i test, anche quando i test, nei framework di automazione, vengono specificati come "funzioni".

Il modello di dominio consiste nella definizione dei concetti propri di un ambito applicativo, e delle loro associazioni.

Se descriviamo un sistema di formazione, saranno concetti come Scuola, Classe, Materia, Insegnante, Allievo. Nella telefonia, saranno concetti come Chiamante, Destinatario, Chiamata, Operatore. In banca, Cliente, Conto, Movimento, Mutuo. Nessun aspetto tecnologico, solo concetti usati da chi opera nell’ambito della materia di riferimento.

La definizione di questi concetti è un aspetto cruciale di ogni progettazione. Prendiamo ad esempio l’ambito editoriale. Cos’è un libro? Cosa si intende per libro?

Il concetto di “libro” può corrispondere a diverse cose, ad esempio a:

• "Promessi sposi" di Alessandro Manzoni (l'opera in sé, indipendentemente dalle diverse edizioni in cui è stata pubblicata, dal 1840 ad oggi)
• "Promessi sposi" di Manzoni, Garzanti, I grandi libri, 2002 (una specifica edizione)
• una copia fisica dell’edizione Garzanti 2002 dei "Promessi sposi"

Tre cose diverse, con ambiguità da chiarire il prima possibile, per progettare, implementare e verificare la correttezza delle funzioni di un sistema in modo da soddisfare i requisiti degli utenti.

La tecnica tradizionale per la definizione del modello di dominio è l’Entity-Relationship (Entità Relazioni) di Peter Chen, proposta negli anni ‘70 per la progettazione logica delle basi dati. Con la diffusione dell’approccio object oriented, la modellazione dei concetti del dominio è poi arrivata a includere anche la dimensione funzionale associata ai concetti, oltre alla parte relativa agli attributi.

Comunque intesa, la modellazione del dominio basata sul significato dei concetti implica una conoscenza approfondita della materia, e costituisce la base per una migliore definizione delle funzioni applicative.

Un modello di dominio efficace può anche migliorare la qualità della collaborazione tra esperti della materia, analisti applicativi e sviluppatori, attraverso la condivisione di conoscenza sui concetti e sul loro significato, con riferimento ad un vocabolario e a delle regole di integrità condivise. E può ridurre notevolmente i rischi di progetto.

L’Agenzia per l’Italia Digitale ha emanato la circolare n. 61/2013, che fa seguito a una legge del 17 dicembre 2012.

Oggetto della circolare, le norme per l'accessibilità dei siti e dei servizi informatici della pubblica amministrazione (ex "Legge Stanca"), che devono essere ora applicate anche da una serie di nuovi soggetti, cioè da tutte le organizzazioni che ricevono contributi pubblici per l'erogazione di servizi informatici.

Interessante flowchart da xkcd:

In ogni processo di sviluppo software pragmatico, requisiti e architettura evolvono insieme.

"The Twin Peaks of Requirements and Architecture" è il tema centrale del numero di marzo / aprile 2013 di IEEE Software.

Un backlog è una lista di cose da fare. Nel backlog dello sviluppo software, le cose da fare appartengono a diverse categorie: nuove funzionalità per gli utenti, adeguamenti tecnici, correzione di errori. Anche la riduzione del debito tecnico rientra tra le cose che è opportuno fare.

Un'utile visualizzazione delle diverse tipologie di attività è stata proposta da Claude Aubry.

Ecco una versione italiana del suo quadrante del backlog: