Progettazione del Software appunti dalle lezioni

Transcript

1 Progettazione del Software appunti dalle lezioni Marco Gasparini Carlo Pane Francesco Solera Università degli Studi di Modena e Reggio Emilia

2 Progettazione del Software, appunti dalle lezioni This report was prepared by Marco Gasparini, Carlo Pane, Francesco Solera Professor Flavio Bonfatti Release date: 2011 Course: Progettazione del Software Department: Comments: Ingegneria Informatica Questo breve documento vuole essere un supporto didattico alle lezioni del corso di Progettazione del Software. È stato scritto a partire dagli appunti presi a lezione ed integrato, qualora ritenuto necessario, con materiale dai libri di testo indicati dal docente e riportati nella bibliografia. Department of Information Engineering Information Technologies and Computer Science University of Modena e Reggio Emilia

3 Introduzione Il corso è indirizzato agli studenti della Laurea Magistrale in Ingegneria Informatica ai quali intende fornire le conoscenze e gli strumenti metodologici fondamentali per l impostazione, l organizzazione e la gestione di progetti software complessi e di grandi dimensioni. Gli argomenti trattati sono: : Economia di un progetto software. Fattibilità di un progetto software, metodo PERT-CPM. Classificazione delle tecniche di stima dei costi e dei tempi di un progetto. Metodo CoCoMo di Boehm (modello base, modello intermedio, cenni al modello dettagliato). Funzione costo di Norden e metodo analitico di Putnam. Le principali variabili di un progetto software. Progetto di piccole, medie e grandi dimensioni secondo Putnam. Curva di sviluppo e curva di progetto. Equazione del software. Software sizing per progetti nuovi e per rifacimenti. Studio del progetto tramite planning zone e punto di lavoro. Metodi avanzati di progettazione del software. Il Processo Unificato (UP). Metodi agili di sviluppo del software e loro principali caratteristiche. Il metodo Agile UP. Il metodo SCRUM. Il metodo Feature Driven Development (FDD). Il metodo Dynamic Systems Development (DSDM). Il metodo Extreme Programming (XP). Tecniche agili di sviluppo del software. Cross-functional team, time boxing, pair programming, test-driven development, code re-factoring. Confronto critico dei diversi approcci. Software Process Improvement (SPI) e Capability Maturity Method integration (CMMi). Linguaggi formali e tecniche di compilazione. Alfabeto, stringa, linguaggio e relativi operatori. Espressioni e linguaggi regolari. Grammatiche generative, definizione formale e classificazione di Chomsky. Grammatiche non contestuali. Alberi sintattici, ambiguit della grammatica. Grammatiche strettamente lineari sinistre, equivalenza con espressioni regolari. Automi a stati finiti, equivalenza con grammatiche strettamente lineari sinistre. Automi non deterministici. Derivazione degli automi deterministici equivalenti, automi minimi. Notazione polacca postfissa e forma a quadruple, generazione del codice oggetto.

4

5 Contents II Metodi avanzati di progettazione del software 1 1 Il Processo Unificato Caratteristiche dello Unified Process Ciclo di vita del progetto Rational Unified Process Modelli agili di progettazione e sviluppo del software Agile UP Scrum FDD Dynamic System Development Method XP Sistemi di qualità ISO Capability Maturity Model integration III Linguaggi formali e tecniche di compilazione 43

6

7 Part II Metodi avanzati di progettazione del software 1

8

9 Chapter 1 Il Processo Unificato Fino ad ora abbiamo sempre avuto a che fare con un metodo di progettazione del software chiamato a cascata. Il modello a cascata o ciclo di vita a cascata (waterfall model o waterfall lifecycle in inglese) è un modello di ciclo di vita del software (ovvero di processo software) secondo cui la realizzazione di un prodotto software consta di una sequenza di fasi strutturata in analisi dei requisiti, progetto, sviluppo, collaudo, integrazione e manutenzione. Ciascuna di queste fasi produce un ben preciso output che viene utilizzato come input per la fase successiva. Purtroppo questo modello viene definito rigido, poiché una volta terminata una fase, questa viene bloccata e diventa insensibile a nuovi requisiti che il cliente potrebbe chiedere o modifiche che il team di sviluppo riconosce come necessarie. Quando si sviluppano software medio-grandi con un modello a cascata occorre mettersi nell ottica che: Il 25%-50% dei requisiti probabilmente cambieranno durante la durata del progetto Almeno il 45% dei requisiti implementati non saranno utilizzati dal cliente Il cliente finanziatore non vedrà niente fino alla fine del processo di sviluppo del software Spesso questi vincoli non risultano essere apprezzati nè dal cliente, che inizia a vedere i risultati dopo lunghi mesi dal momento del finanziamento, nè per il team di sviluppo che è costretto a fare i conti con la rigidità e la linearità di questo approccio. Da queste necessità è nato un nuovo paradigma di progettazione, chiamato Unified Process. Lo UP non è un semplice processo ma piuttosto un framework, un ambiente di lavoro, che dovrebbe essere personalizzato per particolari aziende e progetti. Anche lo Unified Process divide il tempo di sviluppo del software in fasi: Inception, Elaboration, Construction e Transition; per ognuna di queste fasi sono definiti obiettivi ben chiari, ma nessun particolare vincolo è imposto sulle differenti discipline necessarie allo sviluppo (come ad esempio i requisiti). Questa caratteristica permette di riprendere in mano il lavoro già svolto anche in fasi successive e di 3

10 1.1. Caratteristiche dello Unified Process procedere in maniera parallela verso il momento di rilascio del prodotto. Lo UP è particolarmente gradito anche al cliente che può toccare con mano l evoluzione del suo software in una sempre maggiore implementazione dei requisiti. 1.1 Caratteristiche dello Unified Process Iterativo ed incrementale Lo UP è un processo di sviluppo iterativo ed incrementale. Le fasi di Elaboration, Construction and Transition sono divise in una serie di iterazioni di durata definita. Ogni iterazione risulta in un incremento, ovvero in un rilascio del prodotto che contiene funzionalità aggiunte o migliorate rispetto alla release precedente. Nonostante la maggior parte delle iterazioni includeranno contributi da una buona parte delle discipline (requisiti, analisi, progettazione, implementazione e testing), l importanza di questi contributi cambierà nel corso del progetto. Basato sugli Use Case Nello UP, i casi d uso sono usati per catturare i requisiti funzionali e per definire il contenuto di ogni iterazione. Ogni iterazione si occupa di gestire un certo sottoinsieme di casi d uso o di scenari dai requisiti fino all implementazione, test e rilascio. Incentrato sull architettura Per lo UP è importante che l architettura del software sia alla base della preoccupazione e degli sforzi del team di sviluppo. In quanto nessun modello da solo è sufficiente per catturare tutti gli aspetti del sistema, lo UP supporta vari modelli architetturali. Uno degli impegni più importanti del processo di sviluppo è l architettura della baseline eseguibile che viene creata durante la fase di Elaboration. Questa implementazione parziale, dovrebbe rispondere ai requisiti critici e caratteristici individuati in fase di analisi dei requisiti e serve per validare l architettura globale del progetto. Inoltre diventerà, se ritenuta valida, la base per il resto dello sviluppo del software. Pilotato dai fattori di rischio Lo UP richiede che il team di sviluppo sia preoccupato di risolvere i rischi più critici nelle prime fasi del progetto. 1.2 Ciclo di vita del progetto Come già accennato anche lo UP prevede che il ciclo di vita del progetto sia suddiviso in quattro fasi. 4

11 1.2. Ciclo di vita del progetto Il grafo RAPIT Il grafo RAPIT (Requisiti, Analisi, Progettazione, Implementazione, Test) permette di caratterizzare dinamicamente per ogni progetto quando e con quale importanza le varie discipline della progettazione del software entreranno in gioco nelle varie fasi di sviluppo del prodotto. Figure 1.1: Il grafo RAPIT, mette in relazione le discipline della progettazione del software con le fasi di sviluppo del prodotto. Inception L inception è la fase più breve nella progettazione, e così deve essere: una fase di inception prolungata indica un eccessivo lavoro di specificazione a priori, che è contrario allo spirito dello UP. Obiettivo: definire a grandi linee ciò che il software dovrà fare. Artefatti: requisiti principali, valutazione dei rischi, glossario del progetto, una prima documentazione dell architettura, una prima pianificazione dello sviluppo e i prototipi. Elaboration Durante la fase di Elaboration, il team di sviluppo dovrebbe catturare la maggior parte (si può stimare un 80%) dei requisiti del software finale. Comunque lo scopo principale di questa fase è quella di produrre una prima baseline eseguibile che verifichi l appropriatezza del modello architetturale adottato. Una baseline è un implementazione parziale del sistema che include il cuore e le specifiche caratterizzanti del progetto. È costruito e migliorato ciclicamente in una serie di iterazioni e per la fine della fase di elaborazione il modello architetturale deve essere fissato e rimanere stabile fino alla fine dello sviluppo, inoltre la baseline eseguibile deve dimostrare che la scelta dell architettura si rivela appropriata per supportare le funzionalità chiave del prodotto in termini di performance, scalabilità e costi. Obiettivi: creare una baseline eseguibile, perfezionare la valutazione dei rischi, creazione dei casi d uso di circa l %80 dei requisiti fornendo alla fase di costruzione 5

12 1.3. Rational Unified Process una solido piano (di costi e di scadenze) su cui lavorare. Artefatti: baseline, disegno architetturale, documento di valutazione dei rischi, diagrammi dei casi d uso, pianificazione dettagliata. Construction La Construction è la fase più lunga della progettazione. In questa fase quello che rimane del sistema è costruito a partire dalla baseline prodotta dalla fase di Elaboration. Le caratteristiche del software sono sviluppate durante una serie di iterazioni di piccola durata alla fine delle quali deve essere prodotto una nuova baseline eseguibile. Durante questa fase vengono spesso impiegate tecniche di progettazione UML(Activity, Sequence, Collaboration, State (Transition) and Interaction Overview diagrams). Obiettivo: capacitò operativa basilare, ovvero la release prodotta da questa fase deve permettere già l utilizzo delle funzioni caratteristiche del software. Artefatti: prodotto software, modellazione UML, una prima versione del manuale utente ed un piano di testing. Transition La fase finale del progetto è la Transition. In questa fase il sistema è consegnato all utente finale. Con il feedback ricevuto da una release iniziale uscente dalla prima iterazione è possibile apportare modifiche e ridefinire scelte implementative. Obiettivi: rilascio del prodotto, correzione dei difetti, formazione degli utenti utilizzatori. Artefatti: prodotto software testato, risultato del test d accettazione, manuali d uso aggiornati alla release definitiva e accordo di mantenimento. 1.3 Rational Unified Process Il Rational Unified Process (RUP) (che è una estensione dello Unified Process) è un modello di processo software iterativo ed incrementale sviluppato da Rational Software (oggi parte di IBM). Fornisce un approccio disciplinato per l assegnazione dei compiti e delle responsabilità all interno dello sviluppo di un progetto. Il suo obiettivo è assicurare la produzione di un software di alta qualità che incontra i bisogni dei clienti, pur rimanendo all interno di un budget e di una tempistica predefiniti. Caratteristico di questa metodologia è occuparsi di descrivere chi sta facendo cosa, come e quando. Il Rational Unified Process è rappresentato usando quattro elementi primari di modellazione: Workers, the "who": definisce il comportamento e le responsabilità di un individuo, o un gruppo di individui che lavorano insieme come team Activities, the "how": sono unità di lavoro che un individuo in quel ruolo può svolgere, la granularità di un attività è tipicamente dell ordine di poche ore o pochi giorni 6

13 1.3. Rational Unified Process Artifacts, the "what": è un pezzo di informazione che è prodotto, modificato o usato da un processo, gli artefatti sono prodotti tangibili del processo Workflows, the "when": è una sequenza di attività che produce un risultato di valore osservabile Ci sono nove core process workflows o fasi specificate dal modello RUP, le quali rappresentano una partizione di tutti i lavoratori e attività in gruppi logici. Le fasi del ciclo di sviluppo del software sono divise in sei engineering workflows: 1. Business modeling workflow 2. Requirements workflow 3. Analysis & Design workflow 4. Implementation workflow 5. Test workflow 6. Deployment workflow E tre workflows di supporto : 1. Environment workflow 2. Configuration and Change Management workflow 3. Project Management workflow Anche se i nomi delle sei discipline ingegneristiche possono richiamare un idea di processo a cascata, dobbiamo tenere in mente che sono fasi di un processo iterativo e differiscono da queste in quanto sono riviste e riviste per tutta la durata del ciclo di sviluppo del software. Business modeling Uno dei problemi principali nella fase iniziale di progettazione di un software è che il team di software engineering ed il team di business engineering non comunicano in modo appropriato. Questo comporta che il risultato prodotto dal business engineering non è usato in modo appropriato dal team di software engineering e vice versa. Il RUP fornisce un linguaggio ed una metodologia comune per tenere sincronizzati i modelli business e software. Requirements. L obiettivo di questo workflow è di descrivere cosa il sistema dovrebbe fare e permettere agli sviluppatori ed ai clienti di concordare su tale descrizione. Per ottenere questo esplicitiamo, organizziamo e documentiamo le funzionalità, i vincoli e le decisioni prese in fase di analisi. Analysis & Design Il goal principale qui è di far vedere come il sistema sarà realizzato nella successiva fase d implementazione. In breve realizza un astrazione del codice che realizzerà i requisiti individuati. 7

14 1.3. Rational Unified Process Test Gli scopi della fase di testing sono: verificare l interazione fra gli oggetti, verificare l integrazione di tutti i componenti del software, verificare che i requisiti siano tutti correttamente soddisfatti, individuare eventuali problemi prima del rilascio del software. Deployment Lo scopo di questa fase è quello di produrre con successo il rilascio del software e distribuirlo all utente finale. Questa fase comprende anche l assistenza e l aiuto all utente. Environment L obiettivo del workflow di environment è quello di fornire al team di sviluppo un ambiente, che comprende sia metodologie che strumenti, necessari per la progettazione del prodotto, in particolare è importante chiarire le attività volte all inquadramento del processo all interno di un progetto. Configuration and Change Management In questo workflow è descritto come controllare i numerosi artefatti prodotti dalle tante persone che lavorano su un progetto comune. Avere controllo su questo piano significa evitare confusione e assicurare che gli artefatti risultanti non siano in conflitto con altri a causa di accessi multiplo, aggiornamenti simultanei o limitate notifiche. Project Management Software Project Management è l arte di bilanciare gli obiettivi paralleli di un software, gestire i rischi e superare i vincoli, al fine di rilasciare un prodotto che incontra i bisogni del cliente e degli utilizzatori finali. Sviluppo efficace e buone pratiche Il RUP descrive alcune pratiche che sono state osservate in progetti di successo e che si ritiene possano essere d aiuto nello sviluppare in modo efficace software commerciale. Develop software iteratively: data la complessità dei software di oggi è impossibile delineare prima l intero problema, disegnare una soluzione e poi costruire il software e testarlo; è necessario un approccio iterativo che permetta di inserire nella progettazione la comprensione sempre maggiore che il team di sviluppo ha sul problema e sulle funzionalità. Manage requirements: gestire in modo efficiente i requisiti funzionali è fondamentale per la buona riusciuta del software; è importante fin da subito esplicitare, organizzare e documentare le funzionalità richieste ed i vincoli imposti al fine di poter trarre decisioni e valutare compromessi, l importanza di questa pratica è data dal fatto che l implementazione parte proprio da queste considerazioni. Use component-based architectures: il processo si focalizza sull inizio della fase implementativa, si tratta di buttare delle fondamenta che siano robuste e flessibili al tempo stesso, prima di arrivare ad avere una quantità di codice che 8

15 1.3. Rational Unified Process risulta mal strutturata ed ingestibile; a tale scopo sono importanti i concetti di riusabilità e modularità. Visually model software: si tratta di accompagnare alla documentazione scritta anche una modellazione visuale del comportamento dell architettura e dei componenti; questo permette di nascondere inutili dettagli e facilitare la comunicazione di aspetti critici del software. Verify software quality: scarse prestazione e poca affidabilità sono fattori che incidono pesantemente sull accettabilità dei software moderni, quindi la qualità dovrebbe essere valutata tenendo in considerazione fattori come l affidabilità, il rispetto dei requisiti e le performance dell applicazione e del sistema. Control changes to software: l abilità di gestire modifiche - essere sicuri che ogni modifica sia accettabile e rintracciabile - è essenziale in un ambiente in cui le modifiche sono inevitabili. 9

16 1.3. Rational Unified Process 10

17 Chapter 2 Modelli agili di progettazione e sviluppo del software Nell ingegneria del software, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste. La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software. Anche se il risultato di ogni singola iterazione non ha sufficienti funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto. I metodi agili preferiscono la comunicazione in tempo reale, preferibilmente faccia a faccia, a quella scritta (documentazione). Il team agile è composto da tutte le persone necessarie per terminare il progetto software. Come minimo il team deve includere i programmatori ed i loro clienti (con clienti si intendono le persone che definiscono come il prodotto dovrà essere fatto: possono essere dei product manager, dei business analysts, o veramente dei clienti). L agile 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 è stato poi sottoscritto da un nutrito gruppo di questi professionisti, molti dei quali hanno anche sviluppato alcune delle metodologie leggere più famose. L obiettivo è la piena soddisfazione del cliente e non solo l adempimento di un contratto. L uso di queste metodologie, inoltre, serve ad abbattere i costi di sviluppo 11

18 Modelli agili di progettazione e sviluppo del software del software. 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) Considerazioni e buone pratiche La metodologia leggera non nasce per caso, ma come presa di consapevolezza che alcune cose nel mondo della progettazione non andavano. Essa, proprio perché nasce da alcune considerazioni fondanti fornisce e suggerisce alcune pratiche che è bene avere in mente. Risulta particolarmente importante, ad esempio, rilasciare frequentemente software con nuove funzionalità mantenendo in questo modo alta la soddisfazione del cliente. Infatti un software che funziona è molto più apprezzato di un mucchio di documentazione e di fogli di progettazione in corso d opera. Proprio per come è strutturata la metodologia, anche il development team deve essere disposto ad accettare nuovi requisiti, nuove funzionalità da inserire all interno del software anche in fase di implementazione. Questo forse è uno dei frutti principali della stretta collaborazione fra sviluppatori e clienti, il rapporto faccia a faccia impedisce che ci siano periodi di inutile lavoro sprecato poiché cambiato all ultimo. Se il contatto con il cliente è continuo, allora la progettazione risulterà più fluida. Infine il rischio di utilizzare queste metodologie agili, è quello di credere che la progettazione formale sia in secondo piano, il che non è assolutamente vero: è infatti importantissimo tenere in mente che obiettivo principale è sempre quello dell eccellenza tecnica e della qualità. L approccio agile contrappone un approccio adattativo (perché consente di rivedere di continuo le specifiche e di cambiarle durante lo sviluppo mediante un forte scambio di informazioni e di pareri con il committente) rispetto ad uno predittivo (basato su una precisa pianificazione iniziale). È comunque necessario precisare che le metodologie agili non eliminano il concetto di progettazione, semplicemente è una fase trasversale a tutto il ciclo di sviluppo del software. I metodi agili hanno anche altri limiti oltre all inevitabile abbassamento della qualità, riguardante la motivazione. Ossia, per portare avanti un progetto secondo questa metodologia sono necessarie persone disponibili e con particolare esperienza; 12

19 Modelli agili di progettazione e sviluppo del software inoltre le tecniche agili non si comportano bene con progetti enormi, con team distribuiti geograficamente, in aziende che sono particolarmente strutturate e gerarchiche, proprio perché queste situazioni intaccano i principi fondamentali dell Agile Manifesto. Principi comuni dei modelli agili Sin dall inizio deve essere chiaro che questi approcci agili non sono la soluzione a tutti i problemi, non hanno nessuna intenzione di abolire i metodi tradizionali, ma possono introdurre un nuovo modo di affrontare particolari problemi. L approccio agile funziona molto bene in progetti a bassa criticità, se guidati da sviluppatori senior, per software nuovi con requisiti ancora in fase di analisi. Di questi metodi ce ne sono vari, i più famosi sono probabilmente Agile UP, Scrum, FDD, DSDM ed XP. Anche se agili, questi metodi si fondano su un insieme di tecniche, pratiche che permettono di disciplinare la progettazione (Cross-functional team, Time-boxing, Pair programming, Test-driven development, Code refactoring). 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, tuttavia alcune sono comuni. Cross-functional team È l idea di creare team di sviluppo capace di portare avanti simultaneamente tutte le discipline della progettazione del software, quindi dall analisi dei requisiti, implementazione, test, etc. Ha la caratteristica di essere self-directed, riceverà direttive ampie e generali da parte del managment, ma è il team stesso che decide come organizzarsi e come procedere con la progettazione. Questa tecnica porta con sè vari benefici, a partire dal modo di raggiungere gli obiettivi, che passa da uni-directional ad una dinamica interna più ampia; non è prestabilito chi fa che cosa, giorno per giorno. Le informazioni usate dal team per svolgere le proprie azioni è più ampia, più ricca rispetto a quelle di un gruppo monofunzionali (greater scope of information). Non solo, oltre la vastità di informazioni, anche la profondità di queste è notevolmente migliore (greater depth of information): supponiamo di essere in un gruppo di sola implementazione, allora tutto il team potrebbe lavorare esclusivamente su quello che è già stato deciso e congelato dagli analisti precedentemente; al contrario, in un cross-functional team possono essere considerati e rivalutati molti più aspetti, anche in fase di implementazione. Anche le persone coinvolte nel team ne traggono beneficio, non è più possibile utilizzare un gergo specifico o approssimativo nello svolgimento del proprio lavoro; ora che si lavora in un gruppo interfunzionale è necessario essere comprensibili anche ai membri specifici di altre discipline. Time-boxing Questa pratica impone di dividere la progettazione in una serie definita di intervalli di tempo prestabiliti, all interno dei quali il lavoro deve essere portato a termine. Se prima la logica era più incentrata sugli obiettivi (ed il tempo si allungava fino all esaurimento dell obiettivo), ora con il time-boxing è il tempo disponibile ad essere definito (ed eventualmente gli obiettivi vengono ridotti). È importante quindi, che gli obiettivi vengano fin da subito commisurati con più real- 13

20 Modelli agili di progettazione e sviluppo del software ismo al tempo necessario per portarli a termine. All esaurire del tempo predefinito, se l obiettivo è ancora in fase di compimento, posso decidere se cancellare o rischedulare il lavoro in time-boxes successive. Se il vero vincolo del progetto è il tempo di sviluppo, questa tecnica risulta particolarmente benefica. Il time-boxing può essere utilizzata in piccola scala anche da una singola persona che voglia ottimizzare il proprio tempo. Pair programming Questa tecnica agile impiegata in vari metodi consiste nel realizzare lo sviluppo del codice in due persone che se ne stanno insieme davanti al display, uno con il ruolo di driver ed uno con il ruolo di navigator e con lo scambio di questi ruoli particolarmente frequente (30 minuti). Il driver scrive il codice, mentre il navigator anche non volendo svolge un ruolo particolarmente importante: ragiona sull analisi, cioè mentalmente verifica in modo continuativo se il codice scritto rispecchia la sua idea di implementazione dei requisiti, poi inizia a progettare ciò che segue al codice scritto dal driver; infine evidentemente assume un ruolo da debugger in real time, individuando gli errori compiuti dal compagno. È un modo di lavorare molto interessante, che presenta vari benefici ma anche vari limiti di applicazione. Fra i benefici attesi c è la qualità del risultato che risulta essere perfettamente leggibile da due persone, e la cui chiarezza può essere apprezzata anche al di fuori del tipico programmatore, probabilmente il codice risulta essere particolarmente semplice anche se ugualmente efficace. Inoltre, in modo paradossale, il costo del progetto si riduce notevolmente (studi riconoscono l incremento del tempo di programmazione del 15%, ma il 50% in meno degli errori risultante in un 20%-40% riduzione del tempo nella fase di debugging e testing). Questa tecnica può essere utilizzata anche per la formazione di nuovi programmatori, che risultano essere autonomi molto più velocemente che con metodi di apprendimento tradizionali. Risulta didattica anche la scelta di accostare due principianti, che possono aiutarsi nell analisi e nel superamento delle difficoltà. Infine, se per qualche ragione, un dipendente abbandona l azienda, rimane la sicurezza di conoscere il codice. D altra parte, non tutti hanno l attitudine a collaborare e per alcuni l esperienza del pair-programming potrebbe non essere piacevole. Anche un principiante rischia di sentirsi inappropriato ed intimidido se di supporto ad un senior programmer, il quale fra l altro rischia di annoiarsi. Possono inoltre nascere potenziali conflitti dovuti alle differenti metodologie di programmazione utilizzati o dovuti al senso di competizione che può scaturire fra i due. Test-driven development Nello sviluppare il codice, per prima cosa, viene scritto un test sul codice ancora inesistente. Successivamente scrivo il codice che deve superare il test progettato. Se il codice supera il test, allora penso un altro test, altrimenti devo tornare sul codice e cambiarlo. Questo procedimento richiede un ambiente adeguato per scrivere test e sottoporre ai test frammenti di codice. Una seconda osservazione è sulla scrittura dei test: essi sono scritti in modo lineare rispetto allo sviluppo del codice, quindi può risultare particolarmente utile lavorare in coppia, in modo che se uno ha pensato il test, l altro scrive il codice senza sapere come è stato strutturato e quindi viene evitato il rischio di scrivere codici con il solo scopo di passare il test. Nonostante questo l approccio è completamente diverso dal 14