Il processo software

Il processo definisce una cornice per un insieme di aree chiave (KPA Key Process Areas). Le KPA formano la base del controllo gestionale dei progetti software e stabiliscono il contesto in cui si applicano i metodi tecnici, si creano i prodotti intermedi (modelli, documenti, dati, resoconti, formulari e così via), si stabiliscono i punti di controllo (milestone), si garantisce la qualità e si governano in modo opportuno le modifiche .
La maggior parte dei modelli di ciclo di vita del software prevedono una scomposizione del processo di sviluppo in insiemi di attività simili (quando non addirittura identici). La maggior parte delle distinzioni fra diversi cicli di vita verte infatti su altri aspetti, quali:
• l’enfasi relativa che si attribuisce a ciascuna attività.
• l’individuazione degli attori specifici incaricati di ciascuna attività.
• l’ordine in cui le attività si svolgono.

Si istituisce un quadro di riferimento generale del processo, definendo un piccolo numero di attività portanti, comuni a qualsiasi progetto software, quale che sia la sua dimensione e complessità. Una serie di insiemi di compiti consente di adattare le attività portanti alle caratteristiche del progetto software e alle esigenze del team di progetto. Infine le attività ausiliarie (come la garanzia di qualità del software – SQA, la gestione delle configurazioni software e le misurazioni) si sovrappongono al modello di processo. Queste attività sono indipendenti dalle attività portanti e coprono l’intero arco del processo.
Negli ultimi anni si è molto insistito sulla maturità del processo. Il SEI (Software Engineering Institute) ha ideato un modello complessivo, fondato su un insieme di capacità corrispondenti a diversi gradi di maturità di processo di un’azienda. Per determinare il livello di maturità il SEI ricorre a un questionario e a uno schema valutativo a cinque livelli. Il voto finale corrisponde al grado di conformità a un modello di maturità delle capacità (CMM, Capacity Maturity Model), dove sono definite le attività richieste ad ogni livello.
I cinque livelli di maturità sono definiti come segue:
Livello 1: Iniziale. Il processo software è definito di volta in volta e in alcuni casi risulta confuso. Pochi processi sono definiti e la riuscita dipende dall’impegno individuale.
Livello 2: Ripetibile. Presenza di processi basilari di gestione dei progetti, volti a sorvegliare i costi, tempi e funzionalità. La disciplina di processo necessaria ha lo scopo di ripetere il successo di progetti precedenti per applicazioni simili.
Livello 3: Definito. Il processo software, sia per le attività di gestione sia per quelle di realizzazione, è documentato, conforme a uno standard e inserito in un processo software su scala aziendale. Ogni progetto adotta una versione documentata e approvata del processo aziendale per lo sviluppo e la manutenzione del software. Questo livello comprende tutte le caratteristiche definite per il livello 2.
Livello 4: Gestito. Si raccolgono misure dettagliate relative al processo software e alla qualità del prodotto. Sia il processo software sia i prodotti sono valutati quantitativamente e controllati mediante misure dettagliate. Questo livello comprende tutte le caratteristiche definite per il livello 3.
Livello 5: Ottimizzato. Il continuo miglioramento del processo è consentito dalla raccolta di dati quantitativi e dal collaudo di idee e tecnologie innovative. Questo livello comprende tutte le caratteristiche definite per il livello 4.
Il SEI ha associato a ogni livello di maturità alcune aree chiave di processo (KPA). Le KPA descrivono le funzioni (ad esempio pianificazione del progetto software, gestione dei requisiti) che devono essere presenti per garantire un certo livello. Ogni KPA è descritta rispetto alle seguenti caratteristiche.
• Scopi: gli scopi complessivi che la KPA deve raggiungere.
• Impegni: i requisiti (imposti dall’organizzazione) che si devono soddisfare per raggiungere gli scopi che comprovano l’intenzione di adeguarsi a questi ultimi.
• Capacità: tutto ciò che deve essere predisposto (tecnicamente e organizzativamente) per consentire il rispetto degli impegni.
• Attività: i compiti specifici necessari per assolvere la funzione della KPA.
• Metodi di sorveglianza della realizzazione: il metodo in cui verificare la correttezza della applicazione della KPA.
Nel modello di maturità sono definite 18 KPA (ciascuna descritta usando queste caratteristiche), assegnate a diversi livelli di maturità. Eccone l’elenco, ripartito fra i livelli.

Livello 2
• Gestione delle configurazioni software.
• Garanzia di qualità del software.
• Gestione dei sottocontratti per il software.
• Controllo e sorveglianza del progetto.
• Pianificazione del progetto.
• Gestione dei requisiti.

Livello 3
• Revisioni.
• Coordinamento dei gruppi.
• Ingegneria del prodotto software.
• Gestione integrata del software.
• Programmi di addestramento.
• Definizione del processo aziendale.
• Obiettivo primario del processo aziendale.

Livello 4
• Gestione della qualità software.
• Gestione quantitativa del processo.

Livello 5
• Gestione del cambiamento nel processo.
• Gestione del cambiamento tecnologico.
• Prevenzione dei difetti.

Ogni KPA è definita come una serie di pratiche chiave che contribuiscono a raggiungere lo scopo. Le pratiche chiave sono politiche, procedure e attività che si devono mettere in pratica prima che una KPA sia pienamente stabilita. Il SEI definisce così gli indicatori chiave: “quelle pratiche o componenti di pratiche chiave che meglio permettono di stabilire se gli scopi di una KPA sono stati raggiunti”. Per sondare l’esistenza o l’assenza di un indicatore chiave si ricorre ad opportune domande.
IL CMM tuttavia è stato abbandonato dal SEI in favore di un nuovo modello, il CMMI (Capacity Maturità Model Integration). Il CMM è stato sviluppato dal 1987 al 1997. Nel 2002 fu rilasciata la versione 1.1 del CMMI, seguita dalla 1.2 nell’agosto 2006. Il CMMI è un framework metodologico integrato di modelli CMM; si propone di integrare i molteplici modelli CMM sviluppati per settore e comparto industriale, al prezzo di una maggiore generalità.
Il CMMI / MOI è un modello che indica ventidue KPA strutturate su cinque livelli, ognuna con i propri obiettivi generici (Generic Goal) e specifici (Specific Goal). Gli obiettivi generici e specifici sono implementati da una sequenza temporale di attività generiche (Generic practice) e specifiche (specific practice), che hanno determinate tipologie di output (tipical work product).
A loro volta, le attività vengono in alcuni casi dettagliate in una sequenza di secondo livello di sub-attività generiche (generic sub-practice) e specifiche (specific sub-practice).
La generica azienda deve classificare i suoi processi secondo le Process Area indicate nel CMMI per condurre un’analisi dei gap fra la situazione attuale e il “to-be” indicato.
Il SEI ha rilasciato la certificazione CMMI ai processi di una ventina di aziende in tutto il mondo. Si tratta di aziende informatiche delle quali sono stati certificati i processi di ingegneria del software. In Italia ha ottenuto la cettificazione CMMI la sola IBM. Al momento non esistono autority indipendenti autorizzate a certificare i processi di altre aziende secondo il CMMI, e la valutazione è effettuata direttamente dal SEI.
L’elenco completo delle KPA di CMMI è il seguente:
CAR – Causal Analysis and Resolution
CM – Configuration Management
DAR – Decision Analysis and Resolution
IPM – Integrated Project Management +IPPD
MA – Measurement and Analysis
OID – Organizational Innovation and Deployment
OPD – Organizational Process Definition +IPPD
OPF – Organizational Process Focus
OPP – Organizational Process Performance
OT – Organizational Training
PI – Product Integration
PMC – Project Monitoring and Control
PP – Project Planning
PPQA – Process and Product Quality Assurance
QPM – Quantitative Project Management
RD – Requirements Development
REQM – Requirements Management
RSKM – Risk Management
SAM – Supplier Agreement Management
TS – Technical Solution
VAL – Validation
VER – Verification

Ipsec

Affinché dei calcolatori connessi in rete possano reciprocamente scambiarsi informazioni è necessario che gli stessi adottino lo stesso protocollo di comunicazione, che è oramai parte integrante di ogni sistema operativo. Il protocollo di comunicazione (in realtà sono più protocolli) utilizzato dai calcolatori di Internet è noto come TCP/IP (Transmission Control Protocol / Internet Protocol) ed è costituito da diversi protocolli fra cui UDP (User Datagram Protocol) + TCP + IP.
Per consentire la comunicazione tra due calcolatori il TCP/IP stabilisce un “canale” di comunicazione tra il calcolatore del mittente e quello del destinatario. Questo canale attraversa solitamente un numero imprecisato di altri calcolatori, che svolgono le funzioni di “smistatori” (router), il cui compito è quello di indirizzare le informazioni in transito verso il destinatario. La trasmissione di informazioni in Internet è analoga alla trasmissione di una lettera. Per prima cosa la corrispondenza raggiunge l’ufficio postale più vicino al mittente (smistatore di primo livello); questo provvede ad inviare la corrispondenza ad un ufficio centrale, che successivamente la rinvia ad uno o più smistatori intermedi, finché la corrispondenza non arriva all’ufficio postale più vicino al destinatario, dal quale un postino provvede alla consegna. Elemento peculiare del protocollo è che la trasmissione delle informazioni non deve necessariamente seguire sempre la stessa strada, anzi è probabile che due pacchetti dati raggiungano la destinazione seguendo strade diverse. Esistono quindi molti punti in cui l’informazione trasmessa può essere intercettata, letta ed eventualmente modificata. Questa operazione è facilitata dal fatto che le informazioni nell’ambito del protocollo TCP/IP viaggiano in chiaro. Questo rischio può comunque essere evitato operando opportune trasformazioni crittografiche sulle informazioni che devono essere trasmesse. Tali trasformazioni operano una serie di modifiche sul messaggio sino a renderlo illeggibile. Solo il destinatario del messaggio potrà risalire al contenuto originale del messaggio attraverso un’opportuna chiave. IPsec (IP Security) implementa la sicurezza attraverso la cifratura e l’autenticazione dei pacchetti IP. La sicurezza viene quindi fornita a livello rete.
IPsec nasce su iniziativa della Internet Engineering Task Force (IETF) e quindi come Internet Standard. Il progetto completo dell’IPsec definisce un’infrastruttura per fornire molteplici servizi, algoritmi e granularità. La ragione per avere molteplici servizi è che non tutti vogliono pagare il prezzo per avere tutti i servizi disponibili in ogni istante, quindi alcuni servizi vengono resi disponibili su richiesta. IPSEC consente di operare sui messaggi in uscita da un host, le seguenti operazioni:
1. Cifratura dei dati contenuti nei messaggi con appositi algoritmi di crittografia, al fine di consentire la lettura del contenuto originale del messaggio al solo destinatario del messaggio;
2. Autenticazione del mittente: al messaggio vengono aggiunte alcune informazioni supplementari che consentono di verificare l’esatta identità del mittente;
3. Integrità dei dati: al messaggio vengono aggiunte alcune informazioni supplementari che consentono di verificare in fase di ricezione se il contenuto del messaggio rispecchia il contenuto originale oppure se è stato modificato in fase di trasmissione [2].
Tutti questi servizi sono basati sulla crittografia a chiave simmetrica, in quanto le performance sono cruciali. La ragione per avere più algoritmi è data dal fatto che un algoritmo che oggi crediamo sicuro potrebbe essere forzato in futuro. Rendendo l’IPsec indipendente dall’algoritmo, l’infrastruttura può sopravvivere anche se un particolare algoritmo viene forzato. Prevedendo diverse granularità, infine, è possibile proteggere una singola connessione TCP, come tutto il traffico fra due host, oppure il traffico fra due router sicuri, o altre possibilità. Una “connessione” nel contesto deli’IPsec è chiamata SA (Security Association). Una SA è una connessione simplex fra due estremi e ha un identificatore di sicurezza associato. Se è necessario stabilire un traffico sicuro nelle due direzioni, saranno necessarie due SA. Gli identificatori di sicurezza sono trasportati da pacchetti che viaggiano su queste connessioni sicure, e vengono usati (all’anivo dei pacchetti sicuri) per la ricerca delle chiavi e di altre informazioni rilevanti.
Le specifiche tecniche di IPsec contengono due parti principali. La prima parte descrive due nuove intestazioni che possono essere aggiunte ai pacchetti per contenere l’identificatore di sicurezza, i dati di controllo dell’integrità e altre informazioni. L’altra parte, ISAKMP (Intemer Securily Association and Key Management Protocol) concerne lo scambio delle chiavi.
Non tratteremo ulteriormente ISAKMP, in quanto (1) è estremamente complesso, (2) il suo protocollo principale, IKE (Internet Key Exchange), contiene degli errori molto gravi e quindi probabilmente sarà essere rimpiazzato.
IPsec può essere utilizzato in una modalità scelta fra le due possibili. Nella modalità trasporto l’intestazione IPsec viene inserita subito dopo quella dell’IP. Il campo Protocol nell’intestazione IP è cambiato in modo da indicare che un’intestazione IPsec segue quella solita dell’IP (prima dell’intestazione TCP). L’intestazione IPsec contiene le informazioni di sicurezza: principalmente l’identificatore SA, un nuovo numero di sequenza, ed eventualmente un controllo d’integrità del campo payload. Nella modalità tunnel l’intero pacchetto IP. intestazione compresa, viene incapsulato nel corpo di un nuovo pacchetto IP con un’intestazione IP completamente diversa La modalità tunnel è utile quando il tunnel aniva in un posto diverso dalla sua destinazione finale. In alcune situazioni, il tunnel arriva a una macchina con un gateway sicuro, per esempio il firewall dell’azienda. Operando in questo modo, il firewall incapsula e decapsula i pacchetti che lo attraversano. Facendo terminare il tunnel su questa macchina sicura, le machine sulla LAN dell’azienda non devono essere a conoscenza dell’IPsec. Solo il firewall sarà a conoscenza del tunnel IPsec.
La modalità tunnel è utile anche nella situazione in cui si vuole aggregare un’insieme di connessioni TCP, per poi gestirle come un unico flusso cifrato. In questo modo si evita che un intruso possa avere informazioni sul traffico: per esempio chi sta mandando dei pacchetti, a chi li sta mandando e quanti ne sta inviando. Consideriamo il caso in cui, durante una crisi militare, il traffico fra il Pentagono e la Casa Bianca diminuisca di colpo. Simultaneamente, il traffico fra il Pentagono e alcune installazioni militari nelle Montagne Rocciose aumenta della stessa quantità di cui il primo è diminuito. Un intruso potrebbe trarre delle informazioni utili da questi dati. Lo studio della distribuzione del flusso dei pacchetti, anche se cifrati, è chiamato analisi del traffico. La modalità tunnel fornisce un modo per aggirare parzialmente questo tipo di analisi. Lo svantaggio della modalità tunnel è dato dal fatto che aggiunge delle ulteriori intestazioni IP ai pacchetti e quindi aumenta la dimensione del pacchetto in modo sostanziale.
Al contrario, la modalità trasporto non cambia di molto la grandezza del pacchetto. La prima ulteriore intestazione è detta AH (Authentication Header). AH garantisce il controllo dell’integrità e la sicurezza contro gli attacchi di ricezione, ma non la segretezza (cioè non ha cifratura). L’uso di AH nella modalità trasporto è illustrato nella figura seguente.
Nell’IPv.4, AH viene messo fra l’intestazione IP (incluse le eventuali opzioni) e l’intestazione TCP. Nelll’IPv6, AH è gestito come un’altra estensione dell’intestazione e trattata di conseguenza. in effetti, il suo formato è simile a quello di un’estensione standard dell’intestazione IPv6. Il campo payload può essere riempito fino a raggiungere una particolare lunghezza per facilitare l’algoritmo di autenticazione, come mostrato.

Header di autenticazione IPsec nella modalità trasporto per IPv4

Nell’intestazione AH, il campo Next header field serve per memorizzare il valore originale che aveva il campo IP Protocol prima di essere rimpiazzato con il valore 51. Quest’ultimo è usato per indicare che segue un’intestazione AH. Nella maggior parte dei casi, il valore sarà il codice per il TCP (6). IL campo Payload length contiene il numero di word a 32 bit nell’intestazione AH meno 2. il Security parameter index è l’identificatore della connessione. Viene inserito dal mittente per indicare un particolare record nel database del ricevente. Questo record contiene la chiave condivisa usata per questa connessione e altre informazioni sempre relative alla connessione. Il campo Sequence number viene usato per attribuire un numero a tutti i pacchetti inviati in un SA. A ogni pacchetto viene attribuito un numero univoco, incluse le ritrasmissioni.
In altre parole, un pacchetto ritrasmesso prende un numero di sequenza diverso dall’originale (anche se il suo numero di sequenza TCP è lo stesso). Lo scopo di questo campo è quello di evitare attacchi di tipo ripetizione. Questi numeri di sequenza non sono riutilizzati in circolo: se vengono usate tutte le 232 possibili combinazioni, dovrà essere stabilito un nuovo SA per poter continuare la comunicazione.
Infine abbiamo Authentication data, che è un campo a lunghezza variabile che contiene la firma digitale del payload. L’algoritmo di firma elettronica da utilizzare è negoziato quando viene stabilito l’SA. Di solito in questo stadio non viene usata la crittografia a chiave pubblica, perché i pacchetti devono essere elaborati in modo estremamente rapido, mentre tutti gli algoritmi a chiave pubblica conosciuti sono troppo lenti per questo compito. Per questo motivo IPsec è basato sulla crittografia a chiave simmatrica. II mittente e il destinatario stabiliscono una chiave comune prima d’instaurare la SA, che viene usata nel calcolo della firma. Un metodo semplice consiste nel calcolare l’hash sui contenuti del pacchetto e della chiave insieme. Ovviamente, la chiave condivisa non viene trasmessa. Uno schema di questo tipo è chiamato HMAC (Hashed Message Authentication Code). È molto più veloce da calcolare della strategia alternativa, che consiste nell’usare prima SHA-1 per poi passare elaborare il risultato con RSA.
L’intestazione AH non permette la cifratura dei dati, quindi è utile principalmente quando è necessario un controllo d’integrità ma non serve la sicurezza. Una funzione importante di AH è data dal fatto che il controllo d’integrità copre alcuni campi dell’intestazione P, in particolare quelli che non cambiano mentre il pacchetto viene trasmesso da router a router. Per esempio, il campo time to live cambia in ogni salto di router e quindi non può essere incluso nel controllo d’integrità. L’indirizzo IP della sorgente viene incluso nel controllo, in questo modo diventa impossibile per un intruso falsificare l’origine del pacchetto.
L’intestazione IPsec alternativa è ESP (Encapsulating Security Payload). Il suo uso, sia per la modalità trasporto sia per quella tunnel, viene mostrato nella figura seguente.

(a) ESP in modalità trasposto. (b) ESP in modalità tunnel

L’intestazione ESP consiste di due word a 32 bit, che costituiscono i campi security parameters index e sequence number, con funzioni analoghe a quanto abbiamo discusso per AH. Una terza word che di solito segue le prime due (ma che tecnicamente non è parte dell’intestazione) è initialization vector, usato per la cifratura dei dati. Se non viene usata la cifratura, questo campo è omesso.
ESP fornisce un controllo d’intregrità HMAC come AH, ma diversamente da quest’ultimo non lo include nell’intestazione; lo aggiunge invece in coda ai campo payload, come mostrato nella figura precedente. Utilizzare HMAC in coda al payload comporta dei vantaggi nelle implementazioni hardware. in questo caso, HMAC può essere calcolato mentre i bit sono trasmessi verso l’interfaccia di rete, e poi aggiunto alla fine: per lo stesso motivo Ethemet e altre LAN hanno il CRC dopo la fine dei dati, piuttosto che all’inizio. Con AH, invece, il pacchetto va messo in un buffer e la firma calcolata prima di poterlo trasmettere, pertanto questo modo di operare può avere l’effetto di ridurre il numero di pacchetti/sec che possono essere trasmessi.
ESP riesce a fare tutto quello che AH può fare, ha anche delle funzioni aggiuntive ed è più efficiente. La domanda a questo punto e: perché interessarsi ad AH? La risposta ha origini soprattutto storiche: in origine AH si occupava solo d’integrità e ESP solo di segretezza. Successivamente, l’integrità è stata aggiunta a ESP. A questo punto, però, le persone che avevano progettato AH non volevano vederlo morire dopo tutto il lavoro che avevano fatto. Il loro unico punto a favore è che AH controlla parte dell’intestazione IP, mentre ESP non lo fa, ma questo è un argomento debole. Un’altra giustificazione debole è che un prodotto che supporti AH ma non ESP potrebbe avere minori problemi a ottenere una licenza per l’export in quanto non presenta funzioni di cifratura. AH verrà probabilmente eliminato in un prossimo futuro [2].
Il punto di forza di IPSEC è quello di consentire l’esecuzione di tutte queste operazioni in maniera del tutto trasparente rispetto agli utenti e alle applicazioni. Questo significa che è sufficiente installare IPSEC su un host affinché lo stesso possa incominciare a cifrare/autenticare il traffico di rete generato. Nessuna modifica deve essere apportata alle applicazioni o ai servizi che operano sul calcolatore. Un altro aspetto importante è che IPSEC può operare indifferentemente sul traffico di rete generato da una qualunque applicazione senza distinzione alcuna.
I punti di debolezza del protocollo IPSEC possono invece essere così riassunti:
1. E’ uno standard giovane (la sua ultima formulazione risale al 1998) e quindi a oggi è implementato solo su alcune piattaforme (calcolatori e apparati di rete);
2. Le implementazioni dei vari fornitori non sono ancora del tutto compatibili quindi un messaggio IPSEC generato da un host A può non essere riconosciuto da un router o da un altro host B.

Tutto ciò induce ad una accurata valutazione per l’utilizzo di IPSEC su larga scala.
Un ultimo elemento da considerare nell’adozione di tale protocollo è il suo impatto sulle prestazioni del server. IPSEC infatti può appesantire notevolmente l’attività del microprocessore richiedendo continue operazioni di cifratura/decifratura. Nel caso quindi lo stesso debba essere impiegato in sistemi caratterizzati da un elevato traffico di rete si consiglia di valutare con attenzione l’impatto prestazionale

IL WEB 2.0

Il Web 2.0 è una nuova visione di Internet che ha appena cominciato ad influenzare il modo di lavorare ed interagire con le informazioni in rete. Web 2.0 consiste in un insieme di approcci per usare la rete in modo nuovo e innovativo.
Il concetto di “Web 2.0” ebbe inizio con una sessione di brainstorming durante una conferenza tra ÒReilly e MediaLive International. Nella sessione la discussione sulla crisi delle società dot-com fece emergere alcune considerazioni: la rete era tutt’altro che “crollata”, era più importante che mai, con nuove interessanti applicazioni e siti nascenti con una sorprendente regolarità. Inoltre, le società che erano sopravvissute al collasso, sembravano avere alcune caratteristiche in comune. Poteva essere che il collasso delle dot-com avesse segnato per la rete un punto di svolta. Da questa analisi l’impulso ad un rinnovato sviluppo definito “Web 2.0”, da cui nacque la Conferenza Web 2.0 (www.web2summit.com).
Web 2.0 si riferisce alle tecnologie che permettono ai dati di diventare indipendenti dalla persona che li produce o dal sito in cui vengono creati. L’informazione può essere suddivisa in unità che viaggiano liberamente da un sito all’altro, spesso in modi che il produttore non aveva previsto o inteso.
Questo paradigma del Web 2.0 permette agli utenti di prendere informazioni da diversi siti simultaneamente e di distribuirle sui propri siti per nuovi scopi.
Web 2.0 lascia ai dati una loro identità propria, che può essere cambiata, modificata o remixata da chiunque per uno scopo preciso. Una volta che i dati hanno un’identità, la rete si sposta da un insieme di siti web ad una vera rete di siti in grado di interagire ed elaborare le informazioni collettivamente.
Il Web 2.0 è costruito con diverse tecnologie come Ajax, RSS, Open Api.
Ajax è un approccio di sviluppo web basato su JavaScript ed il linguaggio di programmazione XML. Questa miscela permette alle pagine di funzionare come applicazioni per il desktop più che come pagine di contenuto statico antiquate che troviamo di solito sul web.
Tramite i siti potenziati con Ajax, gli utenti possono interagire con le informazioni nelle singole pagine come se stessero usando un’applicazione, abbandonando la vecchia metafora del web come percorso di navigazione sequenziale in mezzo a pagine statiche.
RSS permette agli utenti di ottenere aggiornamenti automatici non appena un sito cambia, anziché controllarlo ogni volta per avere le ultime informazioni. Basta semplicemente iscriversi al feed RSS del sito e non appena il contenuto di tale sito cambia, viene automaticamente inviato al vostro lettore o aggregatore di RSS.
Nel Web 2.0, tramite gli RSS, le notizie, gli articoli ed altri tipi di contenuto sono filtrate e remixate in nuovi oggetti di informazione. E’ proprio nel remixare, nella selezione competente e nella giustapposizione del contenuto e delle informazioni esistenti che risiede il grande potenziale di Web 2.0.
Le open API forniscono all’approccio del Web 2.0 l’accesso ad ampi database informativi proprietari che ancora una volta possono essere utilizzati per creare nuovi mix e combinazioni che altrimenti non sarebbero possibili.

Selenium

Selenium (http://www.openqa.org/selenium/) è uno strumento di test per le applicazioni web. A differenza di FIT/Fitnesse, selenium esegue i test direttamente in un web browser, simulando quindi una vera e propria interazione uomo/macchina. E’ scritto totalmente in javascript e funziona su ogni browser che supporti javascript .Questa è la lista dei browser supportati al momento della scrittura di questo articolo.
Windows:
• Internet Explorer 6.0.
• Firefox 0.8 to 1.5.
• Mozilla Suite 1.6+, 1.7+.
• Seamonkey 1.0.
• Opera 8.
Mac OS X:
• Safari 1.3+.
• Firefox 0.8 to 1.5.
• Camino 1.0a1.
• Mozilla Suite 1.6+, 1.7+.
• Seamonkey 1.0.
Linux:
• Firefox 0.8 to 1.5.
• Mozilla Suite 1.6+, 1.7+.
• Konqueror.

E’ quindi possibile condurre i test sul browser desiderato e con le impostazioni desiderate. Ne consegue che se un utente lamenta un problema con un determinato browser, magari con delle toolbar, componenti aggiuntivi o impostazioni particolari, è possibile riprodurre l’ambiente esatto e eseguire i test in quelle condizioni. Uno strumento utilissimo incluso in Selenium è Selenium IDE, un pratico plugin per mozilla che consente di registrare i test live. I passi necessari per utilizzare selenium sono i seguenti: aprire mozilla, aprire selenium IDE (plugin installato in precedenza) e iniziare a svolgere una serie di operazioni sul sito da testare. Ad esempio:
• Ciccare su un link che porta ad una form e compilarla.
• Fare il submit.
• Evidenziare una frase o una parola nella pagina di risposta del server.
• Dal menu contestuale di mozilla (tasto destro) si trovano comandi come “assert taletesto present” o “verify taletesto present”…
• Il test viene creato ed è pronto per essere salvato in locale.

Soa

Il termine SOA – Service Oriented Architecture indica un’architettura software atta a supportare l’uso di servizi per soddisfare le richieste degli utenti così da consentire l’utilizzo delle singole applicazioni come componenti del processo di business. Nell’ambito di un’architettura SOA è quindi possibile modificare, in maniera relativamente più semplice, le modalità di interazione e combinazione tra i servizi, così come risulta più agevole aggiungere nuovi servizi e modificare i processi per rispondere alle specifiche esigenze di business: il processo di business non è più vincolato da una specifica piattaforma o da un’applicazione ma può essere considerato come un componente di un processo più ampio e quindi riutilizzato o modificato.
L’architettura orientata ai servizi si presenta particolarmente adatta per le aziende che presentano una discreta complessità di processi e applicazioni, dal momento che agevola l’interazione tra le diverse realtà aziendali permettendo, al contempo, alle attività di business di sviluppare processi efficienti, sia internamente che esternamente ed aumentarne la flessibilità e l’adattabilità.
Da un punto di vista implementativo, SOA è un modello architetturale basato su un accoppiamento non stretto fra agenti software. In tale modello un servizio è dato dall’esistenza da due entità qualsiasi che interagiscono con i ruoli di service provider, che fornisce servizi, e di service consumer, che li utilizza. La realizzazione dei ruoli di provider e consumer è ottenuta tramite agenti software che operano per tali entità. L’architettura del sistema software non è legata ad una specifica tecnologia e l’interfaccia del servizio è indipendente dall’implementazione. Pertanto è possibile utilizzare diverse tecnologia quali REST, ROC, DCOM, CORBA, Web Services. Soprattutto i Web Services e le tecnologie ad essi collegati si rilevano estremamente efficaci nel realizzare architetture SOA oriented. Chi progetta applicazioni o integra sistemi non deve necessariamente conoscere i particolari implementativi. Per esempio un servizio potrebbe essere implementato con una applicazione basata su J2EE o .Net e l’applicazione che utilizza il servizio potrebbe essere implementata con altri tipi di piattaforme e linguaggi software. Un’architettura SOA deve rispettare alcune caratteristiche generali: le interfacce del servizio devono essere descritte in termini indipendenti tramite, ad esempio, il linguaggio XML. WSDL (Web Services Description Language) è lo standard di fatto per la descrizione dei servizi. XSD o XML Schema è lo standard di fatto per descrivere la messaggistica del servizio. UDDI (Universal Description, Definition, and Integration) è lo standard di fatto per la gestione dell’indice dei servizi con cui le varie applicazioni possono ricercare l’esistenza di un servizio per poi richiamarlo. Diverse organizzazioni lavorano per definire modelli di riferimento per le architetture SOA e alcune di esse hanno dato una definizione di Service Oriented Architecture. Sono di seguito riportate le definizioni di Service Oriented Architecture date dalle organizzazioni OMG, OASIS, Open Group, W3C.

Firma Digitale

La firma digitale è associata indissolubilmente al concetto di documento elettronico. La recente normativa italiana conferisce ad un documento elettronico firmato digitalmente, utilizzando tecniche di firma asimmetrica, la stessa valenza probatoria di un documento cartaceo munito di firma olografa.
La firma digitale, quindi, esprime un atto volontario di sottoscrizione e, sotto il profilo tecnico organizzativo, deve essere basata su un certificato qualificato (quindi rilasciato da una trusted part detta Certification Authority che, per quanto previsto dalla vigente legislazione nazionale deve essere iscritta nell’elenco pubblico dei certificatori) e creata mediante un dispositivo di firma sicuro (in genere una smart card).
La direttiva europea e la nascita del commercio elettronico, hanno introdotto altri tipi di firma applicabili in contesti diversi da quello di un documento, come per esempio quello dei messaggi di posta elettronica: in questo caso si parla di firma elettronica.
Sia la firma digitale che quella elettronica permettono realizzare un sistema con il quale il mittente possa mandare un messaggio firmato al destinatario in modo che valgano le seguenti condizioni:
1. il destinatario può verificare l’identità dichiarata dal mittente;
2. il mittente non può ripudiare in un secondo tempo il contenuto del messaggio;
3. il destinatario non può falsificare i messaggi del mittente.
Il primo requisito è necessario, per esempio, per i sistemi finanziari. Quando il computer di un cliente ordina al computer della banca di comprare una tonnellata di oro, il computer della banca deve poter essere sicuro che il computer che ha mandato l’ordine appartenga realmente all’azienda sul cui conto verrà addebitato. In altre parole, la banca deve poter autenticare il cliente (e il cliente deve poter autenticare la banca). Il secondo requisito è necessario per proteggere la banca dalle frodi. Supponiamo che la banca compri una tonnellata d’oro e, immediatamente dopo, il prezzo dell’oro cali bruscamente. Un cliente disonesto potrebbe far causa alla banca, dicendo che non ha mai mandato l’ordine di comprare dell’oro. Quando la banca porterà il messaggio in tribunale come prova, il cliente negherà di averlo spedito. Il terzo requisito è necessario per proteggere il cliente, se il prezzo dell’oro sale e la banca tentasse di costruire un messaggio firmato in cui il cliente chiedeva una barra d’oro al posto di una tonnellata. In questo scenario di frode, la banca si tiene per sé il resto dell’oro.
Nel seguito di questo capitolo si illustreranno vari schemi di firma digitale e le loro implementazioni; ove necessario, saranno utilizzati degli esempi di situazioni reali che descrivono i vari scenari in cui ci si può trovare quando si implementano architetture basate sulla firma digitale. Infine si tratteranno brevemente gli aspetti legali legati alla firma digitale.

Firma a chiave simmetrica
Un approccio alle firme digitali è la creazione di un’autorità centrale che le conosce tutte e di cui tutti hanno fiducia: chiamiamolo Big Brother (BB). Ogni utente sceglie una chiave segreta e la porta a mano nell’ufficio di BB. Per maggiore chiarezza chiameremo il primo utente Alice ed il secondo Bob. Quindi, solo Alice e BB conoscono la chiave segreta KA e così via.
Quando Alice vuole mandare un messaggio in chiaro firmato, P, al suo banchiere, Bob, genera KA(B, RA, t, P), dove B è l’identità di Bob, RA è un numero casuale scelto da Alice, t è il timestamp che assicura la freschezza del messaggio e KA(B, RA, t, P) è il messaggio cifrato con la chiave KA. A questo punto Alice manda il messaggio, come nella figura sottostante, BB vede il messaggio da Alice, lo decifra e lo manda a Bob, come mostrato.

Il messaggio per Bob contiene il testo in chiaro con il messaggio di Alice e anche il messaggio firmato KBB(A, t, P). Infine Bob compie le azioni richieste da Alice.
Cosa succede se, in un secondo tempo, Alice nega di aver spedito il messaggio? Il passo 1 è che ognuno denuncia tutti gli altri. Infine, quando il caso arriva in tribunale e Alice continua a negare risolutamente di aver mandato il messaggio in questione a Bob, il giudice chiederà a Bob come può essere sicuro che il messaggio proveniva da Alice e non da un intruso (che chiameremo Trudy). Bob, come primo argomento, fa notare che BB non accetta messaggi da Alice se non sono cifrati con KA, quindi non è possibile che Trudy abbia mandato a BB un messaggio falso spacciandosi per Alice, senza che BB se ne sia accorto subito. Bob a questo punto può presentare la prova A: KBB(A, t, P). Bob afferma che questo è un messaggio firmato da BB, che prova che Alice ha inviato P a Bob. Il giudice chiede quindi a BB (di cui tutti si fidano) di decifrare la prova A. Quando BB testimonia che Bob ha detto la verità, il giudice dà ragione a Bob. Il caso è chiuso.
Un potenziale problema con il protocollo di firma della figura precedente è dato dagli attacchi di tipo ripetizione, che Trudy può eseguire con entrambi i messaggi. Per ridurre l’impatto di questo problema, vengono usati i timestamp. Inoltre Bob può controllare tutti i messaggi recenti per vedere se RA era già stato usato. In caso affermativo, il messaggio viene scartato come possibile attacco di ripetizione. Notiamo che, basandosi sul timestamp, Bob rifiuterà i messaggi troppo vecchi. Per proteggersi contro attacchi di ripetizione istantanea, Bob deve solamente controllare che RA di ciascun messaggio non corrisponda a quello di un messaggio ricevuto nell’ultima ora da Alice. In questo caso Bob può assumere che il messaggio sia una nuova richiesta.

Firma a chiave pubblica
Il problema strutturale della crittografia a chiave simmetrica per la firma digitale è dato dal fatto che tutti devono fidarsi di una autorità centrale (Big Brother), la quale può anche leggere i messaggi di tutti. I candidati più logici per una Autority sono il governo, le banche, i contabili e gli avvocati. Sfortunatamente, nessuna di queste organizzazioni riesce a suscitare un senso di sicurezza totale in tutti i cittadini. Quindi è auspicabile avere un metodo per firmare i documenti che non richieda un’autorità fidata.
Fortunatamente, la crittografia a chiave pubblica può dare un contributo importante in quest’area. Assumiamo che gli algoritmi di cifratura e decifrazione abbiamo la proprietà che E(D(P)) = P (D sta per Decript, E sta per Encript), oltre alla proprietà solita D(E(P)) = P. RSA ha questa proprietà, quindi sappiamo già che la nostra richiesta è ragionevole. Sotto queste ipotesti. Alice può trasmettere un documento, P, a Bob inviando EB(DA(P)). È importante notare che Alice conosce sia la sua chiave privata, DA, sia la chiave pubblica di Bob, EB, e in questo modo riesce a costruire il documento da inviare.
Bob, dopo aver ricevuto il messaggio, lo trasforma come al solito usando la sua chiave privata, ottenendo quindi FA(P) come mostrato nella figura successiva. Bob memorizza il messaggio in un posto sicuro e poi applica EA per ottenere il messaggio in chiaro originale.

Per vedere come funziona la proprietà di firma, supponiamo che Alice in un secondo momento voglia negare di aver mandato il messaggio P a Bob. Quando il caso arriva in tribunale, Bob può presentare sia P sia DA(P). Il giudice può facilmente verificare che Bob ha in effetti un messaggio valido che è stato cifrato con Da, semplicemente applicandogli EA. Visto che Bob non conosce la chiave privata di Alice, l’unico modo in cui Bob può aver ricevuto un messaggio cifrato con quella chiave è una trasmissione da parte di Alice.
Alice avrà diverso tempo libero per pensare a nuovi schemi crittografici a chiave pubblica mentre sarà in prigione per frode e falsa testimonianza.
La crittografia a chiave pubblica per la firma digitale è uno schema elegante, che però presenta alcuni problemi legati principalmente al contesto in cui viene utilizzata, piuttosto che agli algoritmi utilizzati. Come primo punto, Bob può provare che un messaggio è stato realmente mandato da Alice solo se la chiave Da rimane segreta. Se Alice rende pubblica la sua chiave segreta, il discorso non vale più, in quanto chiunque. incluso Bob, potrebbe aver inviato il messaggio.
Per esempio il problema può verificarsi se Bob è l’agente di borsa di Alice. Alice dice a Bob di comprare alcune azioni e obbligazioni. Quasi immediatamente il prezzo cala bruscamente. Con lo scopo di ripudiare il messaggio inviato a Bob, Alice corre dalla polizia dicendo che la sua casa è stata svaligiata e che il PC con la chiave è stato rubato. A seconda delle leggi in vigore nel suo stato di residenza, Alice può essere considerata responsabile del messaggio inviato oppure no; ciò può dipendere anche dal fatto che Alice dichiari di non aver scoperto il furto fino al suo rientro a casa dal lavoro, diverse ore dopo.
Un altro problema con lo schema della firma elettronica si ha quando Alice decide di cambiare la sua chiave. Questa operazione è sicuramente legale, inoltre è una buona idea farla periodicamente. Se in seguito si dovesse andare in tribunale come descritto sopra, il giudice userebbe la chiave corrente EA per verificare DA(P) e scoprirebbe che non produce P.
A questo punto Bob sarebbe in una posizione indifendibile.
In teoria, qualunque algoritmo a chiave pubblica può essere usato per la firma digitale. Lo standard de facto, utilizzato da una grande quantità di prodotti per la sicurezza, è l’algoritmo RSA.

Scrum

Scrum è un approccio allo sviluppo del software che prevede la suddivisione del progetto in iterazioni del progetto dette Sprints. Ad inizio progetto vengono definite le funzionalità che si dovranno implementare chiamate Backlog con le relative priorità. Tali priorità vengono assegnate da un’unica persona, il Product Manager, responsabile del prodotto e della sua visione; senza la sua autorizzazione non è possibile modificare la priorità del Product Backlog. Prima dell’inizio di ogni sprint, il gruppo di lavoro si riunisce con il responsabile del prodotto e insieme concordano gli elementi prioritari del Backlog che si dovranno implementare durante lo sprint. Ogni sprint ha una durata predefinita di 30 giorni ed una volta decisi gli obiettivi, questi non possono essere cambiati (se non dagli sviluppatori stessi) sino alla fine dello Sprint stesso. Al termine di ogni Sprint deve esserci il rilascio del software prodotto che deve essere un qualcosa di tangibile e utilizzabile dal cliente.
Durante lo sprint ogni giorno il team tiene un breve incontro di una quindicina di minuti chiamato Daily Scrum (Scrum è un termine che deriva dal Rugby e indica il “pacchetto di mischia”) dove il capo progetto (Scrum Master) annota i backlog completati e quelli che rimangono ed ogni sviluppatore racconta cosa ha fatto quel giorno e cosa dovrà fare il successivo.
In generale gli Scrum Meeting si tengono generalmente sempre allo stesso posto e alla stessa ora per dare un ben preciso “ritmo” al progetto. Con lo Scrum si ha un ciclo di controllo molto fine che permette capire lo stato quotidiano di avanzamento dei lavori e di scoprire quanto prima eventuali problemi progetto. Da un punto di vista organizzativo Scrum prevede un Product Owner (analogo al Customer in XP) che come committente del lavoro definisce le cose da fare (Product Backlog) e le relative priorità con scadenza mensile. Lo Scrum Master (analogo al Coach di Xp) è invece responsabile di gestire gli allineamenti giornalieri e mensili tenendo quindi traccia dello stato di avanzamento dei lavori e della situazione dei Backlog. Ogni mese (Sprint Review) definisce il lavoro per il mese successivo (Sprint Planning) in base alla priorità evidenziate dal Product Owner e sulle stime di impegno da parte del gruppo di sviluppo. Il gruppo di sviluppo (Scrum Team) crea un elenco (Sprint Backlog) di task (sotto attività del Backlog) da effettuare per raggiungere gli obiettivi del mese, segnala eventuali criticità allo Scrum Master negli allineamenti giornalieri e mensilmente presenta i risultati ottenuti durante lo Sprint. E’ bene precisare, prima di concludere questa breve descrizione, che SCRUM è una metodologia che definisce pratiche per pianificare e gestire i progetti, cioè di Project Management, ma non indirizza la modalità di sviluppo del prodotto (raccolta requisiti, analisi, disegno, sviluppo, test, …) e che quindi occorre integrarlo con altri approcci (XP, FDD, …) per indirizzare il processo di sviluppo.

Extreme programming

Extreme programming (XP) è un processo di sviluppo del software di recente formulazione e in continua evoluzione, incentrato sulla fase di codifica e portato alla ribalta da Kent Beck. Per progetti in cui i cicli di consegna sono molto compressi e con fattori di rischio tecnologico molto elevati piuttosto che seguire un processo di sviluppo “canonico” si segue un processo più “leggero”, “intuitivo” e quindi molto operativo. Si può affermare che XP è “code-centric”: tutte le fasi del ciclo di vita del software vengono compresse a favore dell’attività di codifica. L’XP si basa su dodici pratiche fondamentali (più altre introdotte successivamente) nessuna delle quali è un’invenzione del metodo. XP infatti propone pratiche già usate e consolidate e consiglia di applicarle tutte al massimo delle loro potenzialità: da qui il termine “estrema”. Le principali pratiche indicate da XP sono pair programming, test driver developement, refactoring, Continuous integration, standard e proprietà collettiva.

Il ciclo di vita prevede un’iniziale fase di “esplorazione” (Exploration Phase) dove si iniziano a raccogliere le user story, una versione “leggera” (e informale) degli Use Case previste dai modelli tradizionale di sviluppo software. Successivamente segue la fase di pianificazione (Planning Phase) dove il cliente scrive le “storie” su delle schede assegnando la relativa priorità e definisce i relativi test di accettazione. Le user story devono essere capite dal programmatore che deve stimarle e classificarle in base alla difficoltà (rischio) di realizzazione. Questo evidenzia come XP si spinga nella direzione della responsabilizzazione dei programmatori e della loro capacità di fare tesoro dell’esperienza delle passate iterazioni ed esperienza. Una volta prodotte le user story il cliente sceglie le storie da implementare compatibilmente con tempo e stime per la specifica iterazione. Il metodo suggerito dall’XP per passare dalle storie (descrizione funzionale) alla struttura ad oggetti del sistema è l’analisi con le schede CRC (Classe, Responsabilità, Collaborazione: una tecnica di OOA introdotta da Beck e Cunningham nel 1989). Le schede CRC hanno lo scopo di individuare in modo informale le caratteristiche fondamentali delle classi candidate esplicitandone il nome, la gerarchia e la relativa responsabilità [CRC]. Per user story particolarmente complesse o potenzialmente rischiose è consigliato lo sviluppo di un Architectural Spike. Un’ Architectural Spike è un programma scritto per sperimentare una soluzione, una sorta di prototipo, quasi sempre “usa e getta” per permettere una stima più accurata di una particolare user story.

Definite le User Story d’interesse si passa alla pianificazione dello sviluppo ossia alla assegnazione delle user story da implementare alle varie coppie di sviluppatori (Iterations to Release Phase). Mentre le iterazioni sono della durata fissa di una settimana, la durata di un rilascio varia a secondo che sia deciso per data (generalmente 2/3 mesi di durata) o per funzionalità (quante user story devono essere realizzate per lo specifico rilascio). L’importante è che ogni rilascio produca un sistema funzionante che permetta di ottenere feedback dal cliente. Gli sviluppatori devono sviluppare in modo semplice e concentrandosi sullo stretto richiesto (“il miglior modo per avere meno errori è avere meno codice!”). L’applicazione diventa quindi “il minimo insieme di codice che soddisfa i requisiti emersi” (“keep it simple”). Una riunione al giorno (in piedi!) permette di fare il punto della situazione e evidenziare eventuali problemi. Se l’iterazione è in ritardo, il cliente sceglie che storie differire alla successiva. La possibilità di tracciare il ritardo/anticipo permette di stimare la velocità di sviluppo del gruppo ed eventualmente rivedere la pianificazione del progetto. Terminata la codifica si inizia la fase di test di accettazione mediante sia test automatici al fine di certificare sia la qualità del codice prodotto sia per decidere l’eventuale rilascio (Productionizing Phase).

 

Come si può notare in questo ciclo di sviluppo appena descritto non è prevista esplicitamente né la fase di analisi né la fase di design. Queste fasi nei processi tradizionali (in questo contesto sono chiamate discipline) producono documentazione per il team stesso e per le fasi successive del progetto. In questo processo di sviluppo le fasi di analisi, design e sviluppo sono concentrate in un’unica fase e sulle medesime persone e questo fa sì che non vi sia una necessità immediata di produrre documentazione; in Xp il progetto evolve insieme al codice.

La documentazione del sistema in Xp è descritta mediante una System Methapor, una metafora del sistema che per Kent Beck è uno dei punti chiave dell’Xp. La metafora è una visione del sistema coerente e comprensibile sia dal cliente che dai programmatori. In molti casi la metafora può rispecchiare le entità nel mondo reale gestite dal sistema stesso e serve anche a dare nomi coerenti a classi, variabili e metodi del sistema, in modo che siano comprensibili a tutti i membri del gruppo di sviluppo. Le variabili in gioco in XP sono quattro: costo, tempo, qualità e portata. Generalmente tutte e quattro queste variabili sono fissate dal Management o dal client stesso. Xp dice che solo tre di queste variabili sono fissate a priori, mentre la quarta è il grado di libertà che sarà stabilita dal gruppo di lavoro in base al valore delle altre. In questo modo ad esempio a parità di costo e portata, se il management richiede una maggiore qualità, il tempo viene definito dal gruppo di sviluppo, committente permettendo. Tirando un po’ le somme, Xp si focalizza su gruppi di sviluppo piccoli (sull’ordine della dozzina di persone) per progetti di piccole medie dimensioni dove la stesura/modifica dei requisiti sono all’ordine del giorno. Il processo è semplice, snello e poco burocratico, ma deve essere comunque seguito con molta disciplina. E’ bene sottolineare che per applicare Xp il cliente ha un ruolo molto importante perché deve partecipare sia al progetto che alla sua evoluzione. Il Customer Xp è in ruolo chiave (e quindi anche critico) deve essere un esperto di dominio e quindi conoscere bene il business del cliente. Deve stabilire le priorità delle user story da implementare e specificare i relativi test di accettazione fino a tendere a condividere il successo/insuccesso del progetto. La critica più forte che viene mossa dagli oppositori di XP è che la disciplina funziona solo per buoni programmatori e che è inadatta a contesti progettuali in cui sia richiesta una tracciatura sistematica dei requisiti. Da un punto di vista organizzativo Xp prevede oltre alla figura di programmatore (stima le storie, definisce i task dalle storie, scrive il codice ed i relativi test), il Tester (esegue i test di accettazione e avverte il gruppo di sviluppo in caso di regressioni), il Tracker (tiene traccia della metrica e della storia del processo) ed il Coach; quest’ ultimo più che un Project Manager deve essere il Project Leader che segue/traccia il processo di sviluppo del progetto e aiuta in modo traversale nei casi di bisogno.

Metodologie agili

La nascita delle metodologie agili si può inquadrare nel periodo del boom “Internet” degli ultimi anni 90 dove la produzione di software ha visto riduzioni drastiche dei tempi di sviluppo e di rilascio dei prodotto software passando dall’ordine degli anni all’ordine di mesi. Le metodologie agili vengono anche dette “leggere” (lightweight) e si contrappongono alle metodologie pesanti (heavyweight) come quella waterfall o a certe ‘istanziazioni’ RUP che prevedono un consistente “formalismo”.

L’idea alla base delle metodologie agili è che non sono predittive, cioè non cercano di prevedere come evolverà il sistema software, bensì sono adattive, cioè cercano di capire le pratiche migliori per meglio adattarsi all’evoluzione dei requisiti dell’utente più che del sistema software.

Lo scopo delle metodologie agili è quindi quello di gestire progetti dove i requisiti utente non sono conosciuti a priori o sono “volatili” e quindi il processo non è completamente prevedibile a priori e di conseguenza un approccio predittivo potrebbe risultare poco efficace. Le metodologie agili quindi si concentrano sul facilitare il più possibile le modifiche al sistema basandosi su un processo iterativo composto da fasi di progettazione, sviluppo e test molto brevi al fine di agevolare l’adattamento in corso di sviluppo orientandosi fortemente ai risultati.

Le caratteristiche comuni di una metodologia di sviluppo agile sono:

• La capacità di gestire i requisiti “instabili”: nei progetti in cui si è costretti a “rincorrere” l’evoluzione dei requisiti utente quasi in tempo reale l’adozione di discipline agili è particolarmente indicato
• Adattabilità: adattare piuttosto che pianificare
• Iteratività e incrementalità: fasi ridotte per concentrarsi su piccoli obiettivi in modo ciclico
• Rilasci frequenti: grazie al ciclo di sviluppo concentrato, i rilasci sono più frequenti
• Test: il codice deve essere testato in modo automatico e continuo
• Orientamento alle persone: privilegiare le persone rispetto ai processi
• Collaborazione con il cliente piuttosto che negoziazione del contratto

Il manifesto

La formalizzazione dei principi su cui si basano le metodologie leggere è stata oggetto del lavoro di un gruppo di progettisti software e guru dell’informatica che si sono spontaneamente riuniti nell’Agile Alliance. Il documento finale di questo lavoro, detto Agile Manifesto [Manifesto], è stato poi sottoscritto da un nutrito gruppo di questi professionisti, molti dei quali hanno anche sviluppato alcune delle metodologie leggere più famose. Sono nate diverse metodologie agili come ad esempio XP, Agile Modeling, Agile Data, Scrum, FDD, DSDM, Crystal. Nel seguito di questo paragrafo verranno trattate alcune di queste metodologie.

I Principi

I principi su cui si basa una metodologia leggera che segua i punti indicati dall’Agile Manifesto, sono solo quattro:

• le persone e le interazioni sono più importanti dei processi e degli strumenti (ossia le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto);
• è più importante avere software funzionante che documentazione (bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere il codice semplice e avanzato tecnicamente, riducendo la documentazione al minimo indispensabile);
• bisogna collaborare con i clienti al di là del contratto (la collaborazione diretta offre risultati migliori dei rapporti contrattuali);
• bisogna essere pronti a rispondere ai cambiamenti più che aderire al progetto (quindi il team di sviluppo dovrebbe essere autorizzato a suggerire modifiche al progetto in ogni momento).

Pratiche

Le singole pratiche applicabili all’interno di una metodologia leggera sono decine e dipendono essenzialmente dalle necessità dell’azienda e dall’approccio del project manager. Nella scelta però bisogna tenere conto delle caratteristiche di ogni pratica per i benefici che apporta e le conseguenze che comporta. Ad esempio, in Extreme Programming, si supplisce alla mancanza assoluta di qualsiasi forma di progettazione e documentazione con lo strettissimo coinvolgimento del cliente nello sviluppo e con la progettazione in coppia. Le pratiche più diffuse tra cui scegliere sono simili fra di loro e possono essere raggruppate in categorie:

 

• Automation – Se l’obiettivo delle metodologie leggere è concentrarsi sulla programmazione senza dedicarsi alle attività collaterali, allora possono essere eliminate o automatizzate; la seconda soluzione è migliore perché si può, ad esempio, eliminare la documentazione aumentando il testing, ma non si possono eliminare entrambe; quindi si sceglie che strada si vuole percorrere e si fa in modo da utilizzare strumenti per automatizzare il maggior numero di attività;
• Close Communication – Secondo Alistar Cockburn, probabilmente il primo teorico delle metodologie leggere, questo è l’unico vero aspetto nodale che renda leggera una metodologia. Per comunicazione diretta si intende la comunicazione interpersonale, fra tutti gli attori del progetto, cliente compreso. Ciò serve ad avere una buona analisi dei requisiti ed una proficua collaborazione fra programmatori anche in un ambito di quasi totale assenza di documentazione;
• Customer Involvement – Il coinvolgimento del cliente è qui indicato singolarmente perché ci sono differenti gradi di coinvolgimento possibili; ad esempio in Extreme Programming il coinvolgimento è totale, il cliente partecipa persino alle riunioni settimanali dei programmatori; in altri casi, il cliente è coinvolto in una prima fase di progettazione e poi non più; in altri ancora il cliente partecipa indirettamente e viene usato come test della versione rilasciata;
• Design & Documentation – Pensare che le metodologie leggere eliminino la progettazione e la documentazione è un errore; in effetti non è così, le metodologie leggere introducono un’iterazione nel ciclo di vita del progetto. Quanta progettazione fare e quanta documentazione produrre, escludendo i casi estremi, è una scelta lasciata a chi gestisce il progetto e spesso i teorici dell’Agile Alliance avvisano che è un errore trascurare o addirittura omettere queste due fasi;
• Frequent Delivery – Effettuare rilasci frequenti di versioni intermedie del software permette di ottenere più risultati contemporaneamente: si ricomincia l’iterazione avendo già a disposizione un blocco di codice funzionante in tutti i suoi aspetti, si offre al cliente “qualcosa con cui lavorare” e lo si distrae così da eventuali ritardi nella consegna del progetto completo, si usa il cliente come se fosse un test visto che utilizzerà il software e riscontrerà eventuali anomalie, si ottengono dal cliente informazioni più precise sui requisiti che probabilmente non sarebbe riuscito ad esprimere senza avere a disposizione utilità e carenze del progetto;
• Hierarchy – La scelta di creare una struttura gerarchica all’interno del team di sviluppo dipende molto dall’approccio del project manager, in ogni caso si ha una conseguenza non secondaria facendo questa scelta. Se si decide per una struttura gerarchica ad albero e frammentata si ottiene la possibilità di gestire un numero molto alto di programmatori e di lavorare a diversi aspetti del progetto parallelamente; se si decide per una totale assenza di gerarchia si avrà un team di sviluppo molto compatto e motivato, ma necessariamente piccolo in termini di numero di programmatori;
• Pair Programming – Programmare in coppia, ossia: due programmatori, due sedie, una scrivania, un computer, una tastiera ed un mouse; uno dei due scrive, l’altro verifica, entrambi scelgono la soluzione costruttiva migliore. E’ stato dimostrato che i costi di questa scelta sono inferiori ai benefici che apporta, ma ci sono esempi pratici che indicano come questa pratica possa essere insopportabile per alcuni programmatori e quindi controproducente;
• Refactoring – Ossia la riscrittura completa di parti di codice mantenendone invariato l’aspetto esterno. Nel caso di una funzione ciò significa riscriverne completamente il core mantenendone invariato header ed ovviamente sintassi, trattandola cioè come una black box. L’intervento sul codice può avvenire “con coraggio”, perché si hanno test unitari e funzionali che garantiscono la non regressione dell’intervento. E’ una delle pratiche più diffuse e suggerite, ma anche questa, come il Pair Programming, ha differenti studi che ne attestano l’inutilità ed in alcuni casi la dannosità;
• Reflective Improvement – Nata con l’avvento della programmazione Object-Oriented, non è altro che la presa di coscienza della produzione di conoscenza che si fa in un un’azienda man mano che si produce codice. Questa conoscenza prodotta non deve andare perduta ed è per far ciò che si sfruttano spesso le altre pratiche, come la comunicazione stretta o la condivisione della proprietà del codice;
• Reverse Engineering – Ossia ottenere, spesso in maniera automatica, la documentazione a partire dal codice già prodotto. E’ una delle pratiche più diffuse e più controverse, diffusa perché permette un guadagno enorme in termini di tempo, ma controversa perché spesso la documentazione prodotta è inutilizzabile oppure è prodotta solo per una richiesta burocratica del cliente e non verrà mai realmente utilizzata;
• Simplicity – Uno dei punti chiave delle metodologie leggere, direttamente mutuato dalla programmazione Object-Oriented, è la semplicità. Semplicità nel codice, semplicità nella documentazione, semplicità nella progettazione, semplicità nella modellazione. I risultati così ottenuti sono una migliore leggibilità dell’interno progetto ed una conseguente facilitazione nelle fasi di correzione e modifica;
• Team forming & Code property – La formazione del team di sviluppo è condizionata dalla scelta sulla gerarchia interna, ma segue regole precise che permettono di ottenere un team produttivo nell’ambito della metodologia scelta. Il codice in particolare segue standard precisi al fine di permettere a chiunque di sentirsi a proprio agio con il codice scritto da altri membri del gruppo, visto che si ha una proprietà collettiva del codice. La scelta dei membri del team è condizionata anche alla scelta della proprietà del codice, che può essere individuale o collettiva; nel primo caso la responsabilità sullo sviluppo è individuale, nel secondo dipende da tutto il team e quindi dal project manager;
• Testing – Pratica diffusissima anche prima della nascita delle metodologie leggere, ha prodotto una letteratura vastissima ed una serie di approcci differenti come il Rapid Testing o il Pair Testing. Nell’ambito delle metodologie leggere vengono spesso utilizzati insieme tre tipi di test differenti: i test funzionali, utilizzati per verificare che il software faccia effettivamente ciò che è previsto debba fare, i test unitari, utilizzati per verificare che ogni pezzo di codice funzioni correttamente, e i test indiretti effettuati inconsciamente dal cliente ogni volta che gli si consegna una versione;
• Version Control – Una delle conseguenze dirette dell’iterazione nella produzione è la necessità di introdurre un modello, un metodo, uno strumento, per il controllo delle versioni del software prodotto e rilasciato; uno degli strumenti più diffusi e maggiormente suggeriti per ottemperare automaticamente a questa pratica è CVS [Wiki].
• Continuous integration – Con il termine Continuous Integration si indica una pratica di sviluppo software in cui i membri di un team integrano il loro lavoro frequentemente, tipicamente ogni persona integra al meno una volta al giorno, fino ad arrivare a integrazioni multiple per giorno. Ogni integrazione è verificata da una build automatica (inclusi i test) per scoprire errori di integrazione più velocemente possibile. Molti team trovano che questo approccio porta a un numero significativamente ridotto di problemi di integrazione e permette ad un team di sviluppare software coeso più velocemente. Le pratiche di Continuous integration sono:

• Mantenere un solo repository dei sorgenti.
• Automatizzare la build del progetto.
• Rendere i test sulla build automatici.
• Ogni sviluppatore deve committare almeno una volta al giorno.
• I commit non devono rompere la build sulla macchina di integrazione.
• Mantenere la build veloce.
• Testare in un clone dell’ambiente di produzione.
• Rendere semplice a chiunque di recuperare l’ultima versione del software eseguibile.
• Permettere a tutti di vedere cosa sta succedendo.
• Automatizzare il deploy negli ambienti di test.