UNIVERSITA’ DEGLI STUDI DI TRIESTE


                     FACOLTA’ DI INGEGNERIA

  CORSO DI LAUREA TRIENNALE IN INGEGNERI...
Sommario
Introduzione .......................................................................................................
Introduzione


      Il qui presente lavoro di tesi triennale in Ingegneria Informatica si

colloca nel contesto del proge...
corredata da un esempio pratico, ovvero la progettazione completa di un

reale Use Case del progetto Euridice.

Il lavoro ...
1. Storia dell’ingegneria del software


       L’esigenza di creare una disciplina che si occupasse dei processi

produtt...
ad un sistema informatico nasce una famiglia di programmi che devono

rispondere ad eventi esterni entro tempi prestabilit...
1.1 Ingegneria del Software


      Per software engineering si intende quella disciplina che si occupa dei processi

prod...
software così come è percepita dagli sviluppatori, ed includono verificabilità,

manutenibilità, riparabilità, evolvibilit...
2. Ciclo di Vita del Software


     Il concetto di ciclo di vita e di processo software coincide con la nascita

dell'ing...
•    la determinazione dei requisiti - specifica dettagliatamente le

       funzioni da svolgere, i servizi da erogare e ...
la loro interfaccia ed i dati ai quali possono accedere. Questa

       sottofase riveste un ruolo importante dunque perch...
mercato. Queste attività possono essere volte a correggere errori del

   software, adattarlo a nuovi ambienti operativi, ...
2.1 Processi di sviluppo software


     La maggior parte delle metodologie di sviluppo del software consiste,

almeno in ...
2.2 Metodologie


     Nel campo delle scienze esatte un modello è una formalizzazione

precisa della una realtà mediante ...
sviluppo o codifica: creazione dei moduli con un linguaggio di

       programmazione;

       collaudo:   esecuzione    d...
metodologie che adottano questo modello si distinguono essenzialmente per

la suddivisione e specificazione delle fasi in ...
effettuare salti a ritroso ma vanno ripercorse tutte le fasi in maniera

      lineare;

   • Rigidità: ogni fase viene co...
Si comprende come gli alti costi del software siano dovuti, nel modello

a cascata, a causa proprio delle specifiche poco ...
Modello incrementale


     Questo modello è caratterizzato dalla scomposizione del processo in

una serie di passi sequen...
incrementale dei vari moduli ma soppesando anche le criticità degli stessi è

possibile affrontare i rischi del progetto f...
Stato: Lo stato di un oggetto si accede e manipola mediante messaggi che

invocano metodi, quindi non è direttamente acces...
Generalizzazione

può rivelarsi opportuno evidenziare sottoinsiemi definibili come ulteriori tipi

di oggetto all’interno ...
Interessante approfondire come la descrizione in linguaggio naturale

dei requisiti può essere interpretata direttamente n...
Nell’esporre l’Object Oriented infine non riveste particolare importanza

descrivere la fase di realizzazione. Questo perc...
3. Rational Unified Process


      Il Rational Unified Process è un modello di un processo software

iterativo sviluppato...
•     Insufficiente automazione;

      Il RUP si può descrivere come una collezione di best practices mirate a

evitare q...
La tecnologia di oggi ci offre dei sistemi software estremamente

complessi, non è possibile definire sequenzialmente e di...
comprendere che la qualità è costruita nel processo, in tutte le attività, è

affetta da ogni partecipante al progetto, ha...
software. Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim

Rumbaugh e Ivar Jacobson (detti "i tre amigos...
determinare i tempi, i costi e i rischi dell’intervento progettuale con la

precisione necessaria per la stipulazione di u...
•    Coincidenza del rapporto definizione dello scopo e costo stimato

           con le aspettative del cliente;

      •...
Se il progetto non passa questa milestone, potrebbe ancora essere

abbandonato, oppure dovrà essere revisionato. Al termin...
nuove release. La Transition Phase si introduce quando lo sviluppo iterativo

si porta ad un punto sufficiente per permett...
•   Workflow

    Un workflow è una sequenza di attività che producono un

    risultato in un tempo osservabile

    (I w...
4. Identificazione delle problematiche di progetto

4.1 EURIDICE


      Il progetto Euridice, è un progetto cofinanziato ...
centralizzata, disposizione di informazioni sullo stato della merce in tempo

reale e così via.

      Risulta immediato r...
4.2 Analisi dello scenario


     Prendendo in considerazione il sopra descritto scenario ci si può

facilmente rendere co...
Dato che i “progetti di ricerca” finanziati dall’Unione Europea sono

indetti tramite un concorso fra gli sviluppatori, al...
personale qualificato sia per quanto riguarda il colloquio con gli altri soggetti

esterni, sia per quanto riguarda la con...
L’attenzione ad altre procedure produttive di carattere più scontato

come definizione del cammino critico delle varie sot...
Si può     immediatamente identificare un vantaggio del nuovo

diagramma, il problema menzionato in precedenza sui problem...
Si pensi ora alla composizione dei workgroup in un’azienda

sviluppatrice. Per favorire la produttività si tende ad aggreg...
colloquiare con altri workgroup non connazionali assegnati a sottofasi

relazionate ad essi. Naturalmente non è un problem...
Deve esserci omogeneità nei tool utilizzati per le varie attività e se proprio

ciò non risulta possibile a livello global...
possibile sfruttando tutti i partner coinvolti nel modo migliore per il fine

collettivo. La risoluzione ideale per render...
4.4 Riassumendo


     In seguito all’analisi appena presentata, risultano essenziali molte

procedure nel complesso del p...
realistiche dell’azienda e diminuisce il rischio di disillusioni per il protrarsi

del termine di sviluppo. Inoltre nel qu...
5. Approccio


     Lo sviluppo effettivo di un progetto di ricerca internazionale e

collaborativo sarà estremamente comp...
La situazione ideale prevedrebbe ovviamente il colmare le lacune del

personale, investendo così sui propri dipendenti ed ...
Inserendo questo lavoro in un progetto di ricerca già avviato da diversi

anni come Euridice, risulta difficoltoso estende...
Lo sviluppo di Euridice era per l’appunto giunto alla conclusione della

fase di analisi. Sarà ora necessario cimentarsi n...
5.1 Guida Metodologica alla progettazione


        Vengono di seguito descritti brevemente i fondamenti necessari alla

c...
• sono espressi in linguaggio naturale e sono comprensibili anche a

        lettori non tecnici;

   • descrivendo i casi...
Lo scopo essenziale è chiarire come gli attori interloquiscano con i vari

casi d’uso e di che dati abbiamo effettivamente...
visibile nella figura successiva.




          Per ogni UCR è necessario identificare gli oggetti che partecipano alla

 ...
La figura seguente mostra un diagramma per la realizzazione di un

caso d’uso “Receive Deposit Item”, si può notare che il...
caso d’uso di Euridice fornendo un ulteriore approfondimento al metodi di

sviluppo dei sopra esposti diagrammi.




     ...
Diagrammi di Sequenza


     Il diagramma di sequenza rientra negli Iteration Diagrams. L’obiettivo

di questa categoria d...
del messaggio, esso rappresenta la chiamata del sorgente ad una funzione

del destinatario.




I messaggi possono essere ...
Generalmente si consiglia l’utilizzo di descrizioni testuali sulla parte

sinistra del diagramma in tutti gli snodi princi...
Questi diagrammi utilizzano diversi concetti base del paradigma

Object-Oriented ed altri correlati, fra questi se ne dist...
Ogni oggetto viene rappresentato tramite un rettangolo suddiviso in tre

scomparti, rispettivamente dedicati al nome della...
Gli attributi devono essere indicati per nome con eventualmente il tipo

e il valore di default seguendo il seguente stand...
Diagrammi di Stato


     È utile utilizzare il diagramma di stato per evidenziare come si

comporta un oggetto attraverso...
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Progetto Euridice
Upcoming SlideShare
Loading in …5
×

Progetto Euridice

1,132 views

Published on

Progetto Euridice: Identificazione ed Applicazione delle metodologie di Progettazione

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,132
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Progetto Euridice

  1. 1. UNIVERSITA’ DEGLI STUDI DI TRIESTE FACOLTA’ DI INGEGNERIA CORSO DI LAUREA TRIENNALE IN INGEGNERIA INFORMATICA TESI DI LAUREA IN SISTEMI INFORMATIVI PROGETTO EURIDICE: IDENTIFICAZIONE ED APPLICAZIONE DELLA METODOLOGIA DI PROGETTAZIONE Relatore Laureando Chiar.mo Prof. Fulvio Sbroiavacca Stefano Costanzo Correlatrice Dott.ssa Forcolin Margherita Anno accademico 2008 – 2009
  2. 2. Sommario Introduzione ....................................................................................................... 2 1. Storia dell’ingegneria del software ................................................................ 4 1.1 Ingegneria del Software ............................................................................. 6 2. Ciclo di Vita del Software................................................................................ 8 2.1 Processi di sviluppo software ................................................................... 12 2.2 Metodologie.............................................................................................. 13 3. Rational Unified Process ............................................................................... 24 3.1 Le fasi del RUP ........................................................................................ 29 3.2 Aspetti statici del RUP ............................................................................ 32 4. Identificazione delle problematiche di progetto.......................................... 34 4.1 EURIDICE .............................................................................................. 34 4.2 Analisi dello scenario ............................................................................... 36 4.3 Approfondimento ..................................................................................... 39 4.4 Riassumendo ............................................................................................45 5. Approccio...................................................................................................... 47 5.1 Guida Metodologica alla progettazione ................................................... 51 6. Progettazione di un Caso d’uso .................................................................... 69 6.1 Considerazioni generali sulla realizzazione di un caso d’uso.................. 73 6.2 Progettazione esemplificativa del Caso d’uso WP26.P2.UC3.2 .............. 75 6.2.1 Diagramma di sequenza del Flusso principale ................................. 80 6.2.2 Diagramma delle classi del Flusso Principale ................................... 84 6.2.3 Approfondimento del Notify Management ..................................... 86 6.2.4 Diagramma delle Classi WP26.P2.UCR 3.2 Prova ............................ 93 Conclusioni e Discussione................................................................................. 96 1
  3. 3. Introduzione Il qui presente lavoro di tesi triennale in Ingegneria Informatica si colloca nel contesto del progetto europeo, già in carico alla società Insiel S.p.a., EURIDICE (EURopean Inter-Disciplinary research on Intelligent Cargo for Efficient, safe and environment-friendly logistics) cofinanziato dalla Commissione Europea nell’ambito del Settimo Programma Quadro (Seventh Framework Programme -FP71) . EURIDICE è un progetto di Ricerca che coinvolge 22 partner provenienti da 9 paesi europei che collaborano con la finalità di implementare il concetto di Cargo Intelligente, si tratta quindi di un progetto di logistica che prevede sia la realizzazione della struttura essenziale che la concreta dimostrazione della fattibilità degli obiettivi di progetto. All’inizio di questo lavoro di tesi, nel progetto, si era giunti alla conclusione della fase di analisi e quindi si doveva iniziare la fase progettazione o design. Obiettivo di questa tesi è dettagliare la metodologia di progettazione considerando le caratteristiche di un progetto collaborativo internazionale e fornire le linee guida per il design. A tal proposito è necessario inquadrare le problematiche inerenti lo sviluppo di un progetto distribuito fra un gran numero di partner dislocati in vari paesi europei, quindi verificarne l’impatto allo specifico punto di progresso del progetto ed individuare il metodo di lavoro ed infine produrre una guida operativa a supporto della corrente fase di progettazione 1 http://cordis.europa.eu/fp7/home_en.html 2
  4. 4. corredata da un esempio pratico, ovvero la progettazione completa di un reale Use Case del progetto Euridice. Il lavoro di tesi è stato suddiviso in sei capitoli. Il primo capitolo introduce la materia di interesse, ripercorrendo brevemente la storia dell’ingegneria del software fino alla odierna definizione. Nel secondo capitolo si descrive accuratamente il concetto fondamentale di ciclo di vita del software, esponendo come esso sia composto e i principali tipi di modelli applicati allo sviluppo dei progetti software. All’interno del terzo capitolo si espone il modello di un processo software iterativo sviluppato da Rational Software cioè il Rational Unified Process. Esso riveste una fondamentale importanza nell’odierna visione della produzione dei progetti software. Il quarto capitolo presenta Euridice ed analizza in fasi successive le problematiche sollevate da un progetto internazionale collaborativo per l’organizzazione del lavoro. Nel quinto capitolo si delinea l’effettivo impatto delle problematiche sollevate nella precedente analisi e si definisce un metodo di lavoro per la progettazione. Infine il sesto capitolo si compone della effettiva realizzazione di un caso d’uso ovvero della esemplificazione pratica del metodo di progettazione scelto ad un segmento dei risultati della fase di analisi. 3
  5. 5. 1. Storia dell’ingegneria del software L’esigenza di creare una disciplina che si occupasse dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software si comincia a sentire attorno alla fine degli anni sessanta. Nasce difatti la necessità di sviluppare prodotti sempre più complessi ed evoluti che rispondano alle richieste delle grandi utenze. Più precisamente dal 1950 al 1965 lo sviluppo del software personale era alquanto limitato: tutti i programmi venivano sviluppati in batch2, gli informatici erano pochi ed apprendevano direttamente sul campo. Ciò che veniva sviluppato era pensato per un unico cliente o talvolta addirittura per una unica macchina. Inoltre era comune che ad ogni progetto lavorasse e continuasse a lavorare una sola persona, senza però richiedere che venisse scritta alcuna forma di documentazione. Fino alla nascita dell'ingegneria del software, la realizzazione di prodotti software consisteva soprattutto nel mettere insieme una sequenza di istruzioni di codice per realizzare compiti ben specifici. Dal 1965 al 1975 si assiste allo sviluppo di software pensato per più utenti e per dei sistemi particolari per i quali la correttezza del risultato dipende anche dal tempo di risposta. Inserendo quindi un limite temporale 2 Il termine batch risale all'epoca della programmazione per schede perforate. In quel contesto, i programmatori solitamente non avevano accesso diretto al computer, bensì preparavano i propri programmi "off-line" e li passavano a un amministratore di sistema, il quale aveva il compito di mandarli in esecuzione quando possibile (accodandoli rispetto ad altri programmi in esecuzione e spesso accorpando più programmi in un'unica unità di esecuzione), restituendo poi in seguito i risultati dell'elaborazione agli interessati. 4
  6. 6. ad un sistema informatico nasce una famiglia di programmi che devono rispondere ad eventi esterni entro tempi prestabiliti, nasce il concetto di real- time. Nel 1968 la conferenza NATO tenuta a Garmisch, in Germania, rende chiaro il problema rappresentato dall'incapacità di produrre nei tempi previsti software affidabile e rispondente ai requisiti. A partire dal 1972 e fino al 1988 vengono introdotte nuove tecnologie, nascono i sistemi distribuiti e si afferma la figura specializzata del sistemista informatico. Il costo dell'hardware si abbassa considerevolmente e di conseguenza la tecnologia informatica comincia a diffondersi rapidamente. Organizzazioni come il Pentagono spingono fortemente lo studio di modelli che permettano di minimizzare la quantità di errori all'interno dei software. Il livello qualitativo del software si eleva, si tende a controllare lo sviluppo del software cercando di sviluppare prodotti di qualità a causa della concorrenza affermatasi tra le software house. Con l'introduzione delle tecnologie informatiche anche nel settore industriale e commerciale, bacini di utenza non più tecniche sentono l'esigenza di informatizzare le proprie strutture. Il cambiamento del tipo di utenza genera l’esigenza di curare l'interfaccia grafica presentata all'utente per renderne più intuitivo l’utilizzo. Il software come prodotto industriale diventa anche oggetto di un attento esame per estendere le capacità di realizzazione dello stesso. Nasce in pratica un concetto simile alle ottimizzazioni da catena di montaggio per le industrie del secolo scorso che avevano similmente stravolto il modo di produrre apparecchiature meccaniche. 5
  7. 7. 1.1 Ingegneria del Software Per software engineering si intende quella disciplina che si occupa dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software. L'ingegneria del software si propone degli obiettivi legati all'evoluzione dello sviluppo del software, inteso come attività industriale, sia da un punto di vista tecnologico (per esempio attraverso la definizione di nuovi linguaggi di programmazione) che metodologico (per esempio il perfezionamento dei modelli di ciclo di vita del software). Essa identifica quindi una formalizzazione del processo di realizzazione e di manutenzione di un sistema informativo. Si parla quindi di ciclo di vita3 del software, disciplina che comprende e regolamenta tutte le fasi di un prodotto dalla sua ideazione e realizzazione fino alla conduzione e infine dismissione. Il concetto di qualità viene applicato anche a questa disciplina vista la necessità di rilasciare un prodotto perfettamente funzionante, documentato e facilmente manutenibile. Per qualità del software si intende la misura in cui un prodotto software soddisfa un certo numero di aspettative rispetto sia al suo funzionamento sia alla sua struttura interna. Per rendere valutabile ciò vengono introdotte due famiglie di parametri: esterni ed interni. I primi si riferiscono alla qualità del software così come è percepita dai suoi utenti, e includono correttezza, affidabilità, efficienza, usabilità. I secondi si riferiscono alla qualità del 3 L'espressione ciclo di vita del software si riferisce alla scomposizione di attività di realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato finale è il prodotto stesso e tutta la documentazione a esso associata. 6
  8. 8. software così come è percepita dagli sviluppatori, ed includono verificabilità, manutenibilità, riparabilità, evolvibilità, riusabilità, portabilità, leggibilità, modularità. L'ingegneria del software definisce quindi dei modelli e l’insieme di processi, ovvero sequenze di fasi per la realizzazione di un sistema software, tutte documentate e ispezionabili, che permettano di realizzare prodotti sempre più evoluti e di qualità. 7
  9. 9. 2. Ciclo di Vita del Software Il concetto di ciclo di vita e di processo software coincide con la nascita dell'ingegneria del software, in quanto rappresenta un passaggio storico dallo sviluppo del software inteso come attività artigianale, ovvero affidata alla libera creatività dei singoli individui, a un approccio più industriale, in cui la creazione di programmi e sistemi software viene considerata come un processo complesso che richiede pianificazione, controllo, e documentazione appropriati. L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato finale è il prodotto stesso e tutta la documentazione a esso associata. Fondamentalmente le attività costituenti il processo di sviluppo sono: la fase di Analisi, ovvero l’indagine preliminare sulle caratteristiche che il sistema deve esibire e sul contesto in cui il prodotto software deve inserirsi. Questa fase può essere scomposta in sottoattività quali: • la definizione del problema - comprendere il “problema” che il sistema è chiamato a risolvere; • lo studio di fattibilità - stabilire se gli obiettivi dello sviluppo sono ragionevoli e raggiungibili sia in dal punto di vista tecnico che economico; • l'analisi del dominio - comprendere il contesto o dominio applicativo in cui il sistema dovrà agire; 8
  10. 10. • la determinazione dei requisiti - specifica dettagliatamente le funzioni da svolgere, i servizi da erogare e le caratteristiche non funzionali richieste per il sistema; In senso più ampio si può dire che l’analisi ha lo scopo di definire, il più precisamente possibile, il problema. Questa fase è svolta essenzialmente grazie alla raccolta delle informazioni attraverso colloqui con il cliente. L’attività di analisi si conclude con la produzione di un documento che descrive in modo preciso, ma comprensibile al cliente, ciò che farà il sistema, tale documento viene definito “Documento dei requisiti”. nella fase di progettazione, in funzione dei requisiti evidenziati dall'analisi, si definisce la struttura del sistema da realizzare. Anche questa fase può essere suddivisa in sotto attività: • architettura - definisce le specifiche del prodotto. I requisiti vengono riformulati in modo da essere comprensibili agli sviluppatori ed aderenti alla tecnologia che verrà utilizzata. Nella fase di analisi il software può esser stato suddiviso in moduli di alto livello, bisogna definire come essi si relazionano e quali siano i loro vincoli non funzionali. Questa sottofase porta alla stesura del documento delle specifiche, esse possono essere di due tipi: funzionali e non funzionali. Le prime rappresentano le funzionalità del software, le seconde invece rappresentano i vincoli ai quali deve sottostare il software (tempi, utilizzo di hardware particolari, logistica); • progetto dettagliato - definisce in modo preciso i moduli che comporranno il software e la loro struttura interna. Viene definita 9
  11. 11. la loro interfaccia ed i dati ai quali possono accedere. Questa sottofase riveste un ruolo importante dunque perché si attuano scelte su come si realizzerà effettivamente il prodotto software; è nella fase di implementazione, o codifica, che si procede con la realizzazione concreta del sistema; questa tipicamente consiste nella realizzazione dei vari moduli costituenti. Nella maggior parte dei casi è possibile distinguere almeno due sottoattività per i singoli moduli che costituiscono il sistema: Codifica e Verifica. Complessivamente si tratta di una fase piuttosto tecnica, tutte le decisioni principali sono state prese nelle fasi precedenti; la fase di collaudo, è volta a misurare in che modo il sistema realizzato soddisfa i requisiti stabiliti nella fase di analisi, ovvero a valutarne la correttezza rispetto alle specifiche. Quando ogni modulo è individualmente corretto si passa all’integrazione dei moduli. Viene quindi testato il sistema complessivo: viene confrontato il documento delle specifiche funzionali e non funzionali (“Are we building the product right?”). Quando il sistema si comporta in accordo con il documento delle specifiche, si passa all’installazione dello stesso nel suo ambiente e si procede al collaudo. Il collaudo comprova da parte dell’utente che il prodotto soddisfa i suoi bisogni ed obiettivi. A questo scopo si confronta il sistema con il documento dei requisiti (“Are we building the right product?”); la fase di manutenzione, che comprende tutte le attività di modifica del software successive al suo rilascio presso il cliente o la sua immissione sul 10
  12. 12. mercato. Queste attività possono essere volte a correggere errori del software, adattarlo a nuovi ambienti operativi, estenderne le funzionalità o a revisionarne operazioni regolamentate da nuove leggi. La manutenzione incide sui costi poiché modifica al software comporta ovviamente la necessità di nuovi test, sia relativi alle nuove funzionalità eventualmente introdotte, sia mirati a verificare che le modifiche apportate non abbiano compromesso funzionalità preesistenti. Una linea standard di verifica prevede dei test sui moduli similarmente alla precedente fase di test, ovvero si testa che i moduli funzionino singolarmente e che una volta assemblati continuino a funzionare; In tutti i cicli di vita del software svolge inoltre un ruolo essenziale la documentazione dei prodotti delle varie sottoattività. 11
  13. 13. 2.1 Processi di sviluppo software La maggior parte delle metodologie di sviluppo del software consiste, almeno in linea di principio, in un linguaggio di modellazione e un processo. Il linguaggio di modellazione è la notazione usata dalle metodologie per esprimere le caratteristiche di progetto, mentre il processo è una serie di passi, una sorta di elenco che aiuti ad ottenere risultati di alta qualità in un tempo prefissato. Il processo software è composto da alcune attività che rappresentano un insieme di compiti da svolgere per sviluppare un software: Attività portanti: una serie di compiti da svolgere necessariamente; Attività ausiliarie: possono aumentare la qualità di un software da produrre, di solito tali attività sono considerate dalle aziende che cercano una certa qualità. Tali attività non riguardano il progetto in sé ma piuttosto l'azienda; Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla modifica di un software, adottano necessariamente un certo approccio nel modo di relazionarsi con i propri clienti, nell'organizzare il proprio lavoro, nella scelta delle tecniche da utilizzare. In modo consapevole o meno, ogni sviluppatore o gruppo di sviluppatori software ha un proprio processo di sviluppo, esso è definito dal proprio modo di lavorare, basato sulla propria esperienza, sulla propria cultura, e sul contesto culturale ed organizzativo in cui si trova ad operare. La storia dei successi e degli insuccessi dei progetti di sviluppo software ha insegnato che ogni processo di sviluppo ha i propri pregi ed i propri limiti. E che un processo di sviluppo inadeguato alle concrete esigenze dello specifico progetto può condurre al fallimento del progetto stesso, o comunque all'insoddisfazione dei clienti e degli stessi sviluppatori. 12
  14. 14. 2.2 Metodologie Nel campo delle scienze esatte un modello è una formalizzazione precisa della una realtà mediante equazioni matematiche. Nello sviluppo del software, il modello è chiaramente meno preciso, ma comunque l’applicazione di un modello, magari impreciso ma aderente al caso, è pur sempre preferibile alla non applicazione di un modello. Questa affermazione è particolarmente evidente per lo sviluppo di progetti software, a tal riguardo nel tempo si sono affermate numerose e diverse metodologie per rispondere al progresso tecnologico e al conseguente modificarsi delle potenzialità del software. Vediamo ora alcune diverse tipologie di modelli: Modello a cascata Questo modello è caratterizzato da un rigida suddivisione in passi sequenziali ognuno dei quali definisce una attività che opera su un insieme di ben definiti input e produce determinati output che serviranno come input della fase successiva. Importante sottolineare che viene regolamentata la documentazione delle varie fasi del processo. Il modello a cascata tradizionale prevede le seguenti fasi: studio di fattibilità: ha lo scopo di determinare se intraprendere lo sviluppo del sistema; analisi dei requisiti: ha lo scopo di determinare che cosa farà il sistema; progettazione: ha lo scopo di determinare come il sistema farà quanto stabilito nella prima fase, e in particolare la sua suddivisione in moduli e le relazioni fra di essi; 13
  15. 15. sviluppo o codifica: creazione dei moduli con un linguaggio di programmazione; collaudo: esecuzione di prove per verificare la correttezza dell'implementazione dei singoli moduli; test di integrazione: esecuzione di prove per verificare la correttezza del funzionamento complessivo del sistema; manutenzione: segue la consegna o delivery del prodotto al cliente, e comprende tutte le attività volte a migliorare, estendere e correggere il sistema nel tempo; Nel contesto di una specifica organizzazione, il modello a cascata può essere ridefinito in molti modi, inoltre un'organizzazione può formalizzare ulteriormente il processo definendo standard e imponendo vincoli per quanto riguarda la natura, il formato, la struttura e i contenuti dei documenti prodotti nelle varie fasi, tipicamente allo scopo di consentire un controllo più rigoroso sullo stato di avanzamento del progetto e sulla qualità del lavoro svolto. Il modello ha giocato un ruolo importante nello sviluppo del software per superare i limiti del processo del “code and fix” e infine ha fissato due concetti: • Il processo di sviluppo del software deve essere soggetto a disciplina e pianificazione; • L’implementazione del prodotto deve essere rimandata fino a quando non sono perfettamente chiari gli obiettivi. Il maggior pregio di questo metodo di lavoro è certamente la semplificazione del controllo dell’andamento del progetto tramite la suddivisione del ciclo di vita in fasi successive ben definite. Le diverse 14
  16. 16. metodologie che adottano questo modello si distinguono essenzialmente per la suddivisione e specificazione delle fasi in sottofasi più elementari, nella definizione di standard di documentazione e nella individuazione di momenti di verifica, detti milestone, al termine o durante ciascuna attività. Per ottimizzare il ciclo di vita, la scomposizione delle fasi in sottofasi persegue l’obiettivo di assegnare a ciascuna fase la soluzione di problematiche specifiche e di rendere, per quanto possibile, le fasi indipendenti allo scopo di poterne parallelizzare le attività. Benché l’adozione di questi principi appaia estremamente produttiva, la loro applicazione pratica ha come effetto collaterale, soprattutto per i progetti di grandi dimensioni, una pericolosa dilazione temporale. Ad esempio, normalmente l’individuazione delle strutture dati e delle funzionalità del sistema sono affrontate con metodologie diverse e, soprattutto per i progetti di grandi dimensioni, contemporaneamente e separatamente da gruppi di lavoro differenti. Nel primo caso i risultati sono formalizzati con uno Schema Entity-Relationship e nel secondo con un metodo di scomposizione funzionale. Solo quando queste due attività terminano viene avviata una ulteriore attività di armonizzazione dei rispettivi risultati. Un ulteriore problema di questa impostazione deriva dalla necessità di terminare completamente tutta la fase di analisi dei requisiti e progetto per cominciare l’implementazione e quindi verificarne sul campo le conclusioni. Il modello, quindi, è una semplificazione della realtà che non trova piena applicazione in quanto vengono applicati i seguenti tre principi: • Linearità: spesso si hanno cicli di feedback per la correzione degli errori. Tale feedback deve essere lineare e quindi non si possono 15
  17. 17. effettuare salti a ritroso ma vanno ripercorse tutte le fasi in maniera lineare; • Rigidità: ogni fase viene congelata quando si passa alla fase successiva per cui non è possibile un’interazione tra clienti e sviluppatori durante il ciclo di vita dopo la parte iniziale; • Monoliticità: tutto il modello è orientato alla singola data di rilascio che spesso si pone a mesi o anni dopo l’inizio della prima fase per cui se vengono commessi eventuali errori o cambiano i requisiti, questi verranno implementati dopo parecchio tempo e comunque alla fase di consegna seguirà subito un altro adattamento perché il software sarà già obsoleto; Concludendo quindi, in base alle nozioni appena riportate si possono identificare i maggiori problemi del modello: • È difficile stimare le risorse e i costi in maniera accurata finché non sia stata svolta almeno la prima fase di analisi; • La specifica dei requisiti produce un documento scritto che vincola il prodotto da sviluppare e ciò non sempre soddisfa le esigenze del cliente perché si tratta pur sempre di specifiche basate su un documento che non sempre aiuta nel definire le esigenze, che invece, appaiono subito chiare dopo il primo rilascio del software. Inoltre tale documento deve essere completo e chiaro prima di procedere allo sviluppo, ma non sempre ciò è possibile; • L’utente non è in grado di comprendere i formalismi utilizzati per descrivere i requisiti dell’applicazione, si corre quindi il rischio di passare alla fase di progetto con una documentazione non del tutto aderente agli obiettivi del cliente; 16
  18. 18. Si comprende come gli alti costi del software siano dovuti, nel modello a cascata, a causa proprio delle specifiche poco complete e ai molti interventi successivi per introdurre funzionalità non previste in partenza. La curva di costo degli errori in questo modello è esponenziale proprio perché data la monoliticità più tardi ci si accorge di un errore e più profonda dovrà essere la correzione da apportare. Modello esplorativo Se non si possono determinare le specifiche, non può essere definita la correttezza del sistema, ossia la corrispondenza con le specifiche. In questi casi viene utilizzato il concetto di adeguatezza, ossia corrispondenza con i bisogni e gli obiettivi del cliente. Il modello esplorativo consiste in una successione di prototipi che viene fatta convergere verso una soluzione adeguata, soddisfacente per il cliente. Non si tratta di una vera metodologia quanto piuttosto di un approccio sperimentale e iterativo allo sviluppo: ad ogni iterazione viene costruito un prototipo e presentato alla valutazione critica del cliente, che lo può accettare come adeguato alle sue esigenze, oppure può indicare nuovi criteri e requisiti che il sistema deve possedere. Nei passi finali il prototipo viene affinato ad ogni ciclo finché viene accettato dal cliente. Questo modello presenta due caratteristiche salienti: • Non vi è distinzione tra prototipo finale e prodotto. Questo normalmente non risulta vantaggioso per il fornitore; • Vi è un forte coinvolgimento del cliente nella fase di sviluppo rispetto al modello a cascata con conseguenti costi anche per il cliente. 17
  19. 19. Modello incrementale Questo modello è caratterizzato dalla scomposizione del processo in una serie di passi sequenziali da ripetere ad ogni termine del ciclo precedente. Per poter applicare questo modello è consigliabile avere una visione molto chiara dell’intero progetto, perché occorre fare in modo che la realizzazione della generica versione k risulti utile per la realizzazione della versione k+1. Per fare ciò bisogna eseguire con cura la fase di analisi (definizione del problema, analisi di fattibilità, e così via) e poi procedere con l’iterazione del seguente ciclo di attività: • analisi dei requisiti • progetto • codifica • test o collaudo Importante osservare che ogni iterazione ha un piano, degli obiettivi verificabili e criteri di valutazione propri, ciò permette un migliore controllo del lavoro. Ogni qual volta che si termina una iterazione del ciclo si ha realizzato uno o più moduli funzionanti che vengono integrati e testati con quelli precedentemente sviluppati creando una versione funzionante del progetto che implementa un sottoinsieme finito delle funzionalità del progetto software totale. Si procede in maniera analoga fino all’ennesima iterazione e quindi alla conclusione del ciclo con il rilascio della versione finale. Questo tipo di approccio offre delle differenze sostanziali rispetto il modello a cascata visto in precedenza; organizzando le iterazioni cercando di dare una priorità di messa in opera non solo dipendente dall’utilità 18
  20. 20. incrementale dei vari moduli ma soppesando anche le criticità degli stessi è possibile affrontare i rischi del progetto fin dall’inizio, in modo sistematico. Inoltre operare con un sistema stratificato di release permette una maggiore flessibilità per gestire eventuali cambiamenti esterni (tecnologie, leggi) o interni (errori nel documento dei requisiti) e favorisce la partecipazione del cliente alla vita del progetto; tutto ciò accresce ovviamente il costo per il cliente ma offre la possibilità di fornire velocemente software funzionante e fornire risultati di valore poiché questo modello consente una progettazione adeguata, in quanto porta ad un progetto solido. Object Oriented Nell’Object Oriented l’importanza fondamentale è rivestita dall’approccio che si adotta per la scomposizione del problema. Questo metodo mira infatti ad una decomposizione di un sistema mediante l’astrazione di oggetti, che è diversa dalla decomposizione funzionale/procedurale. Tutti i linguaggi ad oggetti includono sempre un tipo di modulo chiamato classe, esso è uno schema dichiarativo che definisce tipi di oggetti. La dichiarazione di classe contiene implicitamente la definizione dei dati e dei metodi che operano su di essi. Per poter continuare la spiegazione liberamente si introducono le definizioni di alcuni termini propri dell’ Object Oriented specifici della definizione di una classe: Classe: Nome collettivo di tutti gli oggetti che hanno gli stessi metodi e variabili di istanza (dichiarazione di tipo); Oggetto: Entità strutturata (codice, dati) e proprietaria di uno Stato la cui struttura è invisibile all’esterno dell’oggetto; 19
  21. 21. Stato: Lo stato di un oggetto si accede e manipola mediante messaggi che invocano metodi, quindi non è direttamente accessibile; Variabili di istanza: Variabili contenute nell’oggetto che rappresentano il suo stato interno; Messaggio: Richiesta ad un oggetto di invocazione di uno dei suoi metodi; Metodo: Azione che accede o manipola lo stato interno dell’oggetto (di solito le variabili di istanza), l’implementazione di tale azione è nascosta al cliente che spedisce messaggi all’oggetto. Approfondita ora la definizione e terminologia di una classe risulta più semplice introdurre i concetti propri dell’Object Oriented: Classificazione la definizione di classi rappresenta l’identificazione di un insieme di attributi (variabili di istanza) e di operazioni (metodi) propri di oggetti simili. Proprio per questo motivo si può dire che una classe descrive un insieme di oggetti e lo rappresenta tramite un’astrazione degli attributi rilevanti; Responsabilità ogni classe ha una responsabilità limitata ai comportamenti che essa prevede (ai metodi che implementa); Ereditarietà questo concetto indica che una classe, detta sottoclasse, può essere un raffinamento di un’altra andando così a richiedere alcune variabili e/o metodi aggiuntivi rispetto alla classe raffinata, che viene denominata superclasse. Il vantaggio è quindi l’utilizzo condiviso delle definizioni di attributi e codice in classi diverse, rendendo quindi sufficiente la sola definizione delle variabili e dei metodi aggiuntivi; 20
  22. 22. Generalizzazione può rivelarsi opportuno evidenziare sottoinsiemi definibili come ulteriori tipi di oggetto all’interno di classi già identificate. Questo concetto è identificabile banalmente come la relazione di contenimento in insiemistica (un semplice esempio può essere Veicolo Moto); Polimorfismo si vuole rendere standard che le operazioni con lo stesso significato posseggano lo stesso nome anche se implementazioni diverse. Si intuisce che esse verranno identificate univocamente dall’insieme di variabili su sui operano (esempio “calcolo_area” su figure geometriche diverse); Information Hiding ogni classe nasconde tutto ciò che non è essenziale condividere, impedendone così l’accesso o la modifica diretta e non facilmente controllabile dall’esterno; Gettati i punti essenziali dell’Object Oriented si può vedere ora la struttura della sua applicazione, limitiamoci a descrivere una scomposizione in tre fasi: Analisi, Design e Realizzazione. I processi Analisi Object Oriented hanno tutti la seguente struttura: • Identificazione dei requisiti; • Inquadramento di scenari e delle interazioni fra attore e sistema (casi d’uso); • Estrazione delle componenti candidate; • Costruzione di un modello di relazioni fra le componenti; • Costruzione di un modello di comportamento delle componenti; • Revisione dell’analisi rispetto ai casi d’uso; 21
  23. 23. Interessante approfondire come la descrizione in linguaggio naturale dei requisiti può essere interpretata direttamente nella identificazione delle entità e dei loro attributi e metodi. Se si provvede a separare ogni frase dei requisiti in gruppi attinenti agli stessi soggetti risulta chiaro come ogni sostantivo può essere identificato come oggetto ed ogni verbo può essere identificato come metodo. Ovviamente è necessario porre attenzione ai significati di sinonimi e differenti modi di riferirsi al medesimo oggetto. Dopo aver completato la fase di analisi si ha dunque una totale scomposizione del problema in componenti e dei modelli in cui vengono definite le loro relazioni e i loro comportamenti. La fase di Design deve ora specificare completamente queste componenti facendo riferimento anche ai vincoli tecnologici che si impongono al progetto. Bisogna misurare il grado di indipendenza dei vari componenti. Inutile sottolineare che le componenti di un sistema dovrebbero riportare un basso accoppiamento, limitando il numero di dipendenze e lasciando solamente quelle funzionalmente rilevanti e necessarie. Si rivela essenziale definire una gerarchia fra i componenti del sistema, riducendo le dipendenze e vincolando la topologia delle relazioni fra i moduli. Una struttura gerarchica forma la base del progetto decomponendone il dominio e facilitandone lo sviluppo in parallelo. Riassumendo i concetti dell’approccio Object Oriented al design si può dire che: • le componenti vengono classificate • astrazione e incapsulamento sono meccanismi principali della strutturazione • il sistema finale rispecchia il dominio del problema • è possibile la concorrenza dei processi (thread multipli) 22
  24. 24. Nell’esporre l’Object Oriented infine non riveste particolare importanza descrivere la fase di realizzazione. Questo perché se le precedenti fasi sono state eseguite con la dovuta meticolosità e non sono presenti errori, si tratta solamente di riportare le classi nel o nei linguaggi scelti e di sviluppare le interfacce necessarie, riducendosi così ad una mera procedura di programmazione. 23
  25. 25. 3. Rational Unified Process Il Rational Unified Process è un modello di un processo software iterativo sviluppato da Rational Software. Esso provvede a fornire un approccio disciplinato per l’assegnazione dei compiti e delle responsabilità all’interno di una organizzazione di sviluppo software. Il suo obiettivo è garantire una produzione di alta qualità che trovi un punto di incontro fra le esigenze dei clienti e le tempistiche e il budget dell’azienda. Il R.U.P. non definisce un singolo, specifico processo, bensì un framework adattabile che può dar luogo a diversi processi in diversi contesti, esso è pensato principalmente per i progetti di grandi dimensioni. Interessante è sapere come è nato, i creatori del RUP partirono dalla diagnosi di un campione di progetti software falliti, allo scopo di identificare cause tipiche o generali di fallimento. Quindi confrontarono questa informazione con la struttura dei processi software descritti in letteratura e applicati nella pratica, cercando di identificare le soluzioni proposte precedentemente. L'elenco dei motivi di fallimento identificati comprende per esempio: • Gestione ad hoc dei requisiti; • Comunicazione ambigua e non precisa; • Architettura fragile ,incapace di sopportare situazioni di particolare criticità; • Incapacità di gestire la complessità; • Inconsistenze nei requisiti, nel progetto o nelle implementazioni; • Collaudo insufficiente; • Valutazione soggettiva dello stato del processo; • Incapacità di affrontare il rischio; • Propagazione non controllata delle modifiche; 24
  26. 26. • Insufficiente automazione; Il RUP si può descrivere come una collezione di best practices mirate a evitare questi e altri problemi, e come un ambiente di gestione dei processi che facilita l'applicazione di tali pratiche. Il processo fu progettato utilizzando strumenti tipici della progettazione del software; in particolare, esso fu descritto in termini di un meta modello object-oriented, espresso in UML. Per l’appunto chiameremo da ora in poi queste diverse metodologie di approccio descritte dal RUP come processi o “best practices”, vediamo ora le sei più importanti: • Sviluppo software iterativo (Develop Software Iteratively) • Disciplina dei requisiti (Manage Requirement) • Utilizzo di architetture a componenti (Use Component-based Architectures) • Verifica della qualità del software (Verify Software Quality) • Controllo dei cambiamenti (Control changes to software) • Modellizzazione Visuali (Visually Model Software) Disciplina dei requisiti Il RUP descrive come identificare e tracciare i documenti funzionali necessari, definire i vincoli, estrarre, organizzare e comunicare semplicemente i requisiti del business. Le nozioni di “use case” e di scenari sono state dimostrare essere degli eccellenti modi di procedere al fine di catturare e definire i requisiti funzionali ed assicurare che essi guidino correttamente il design, l’implementazione e il test del software, portandolo così ad adempire fedelmente alle necessità del cliente. Sviluppo software iterativo 25
  27. 27. La tecnologia di oggi ci offre dei sistemi software estremamente complessi, non è possibile definire sequenzialmente e di primo acchito l’intero problema, effettuarne il design, codificarlo e testarlo solo al termine del processo produttivo. Un approccio iterativo è richiesto per permettere una comprensione progressiva del progetto e quindi un suo raffinamento al fine di far crescere l’effettiva soluzione migliore su questo ciclo di iterazioni multiple. Questa struttura permette tramite lo sviluppo dei maggiori oggetti di rischio nelle prime iterazioni, di mantenere sotto controllo il rischio durante tutto il ciclo di vita del software. Un approccio iterativo facilita l’adeguamento degli obiettivi di progetto ai cambiamenti, andando a ridurre significativamente il costo dei cambiamenti dovuti ad errori a qualsiasi livello. Controllo dei cambiamenti L’abilità di controllo e gestione dei cambiamenti è essenziale per rendere ogni necessità di alterazione accettabile e permettere di tracciare come essa inevitabilmente affonderà e richiederà delle modifiche nel progetto. Questo processo descrive come controllare, tracciare e monitorare i cambiamenti per poter sviluppare iterativamente ed efficacemente a fronte del presentarsi di errori. Verifica della qualità del software Oggigiorno cattive performance applicative e scarsa affidabilità sono comuni fattori che segnano l’inaccettabilità del software. Quindi, si rende necessario un controllo qualitativo basato sui requisiti sull’affidabilità, la funzionalità, le performance delle applicazioni e dell’intero sistema. Il RUP mette a disposizione dei parametri valutativi per i test di pianificazione, design, implementazione, esecuzione e valutazione. È importante 26
  28. 28. comprendere che la qualità è costruita nel processo, in tutte le attività, è affetta da ogni partecipante al progetto, ha dei criteri e parametri di valutazione definiti e non deve essere trattata come una attività separata svolta da un gruppo dedicato come aggiunta al progetto. Utilizzo di architetture a componenti Il processo è centrato sul definire la linea guida di una architettura eseguibile robusta e svilupparne velocemente alcune parti, prima di impegnare le risorse per uno sviluppo massivo. Esso descrive come disegnare una architettura ricuperabile che sia flessibile ed adattabile ai cambiamenti, e come è intuibile che favorisca il riutilizzo del software interno. I componenti non sono meri moduli ma sottosistemi che adempiono a specifiche funzioni. Il RUP provvede a definire un approccio sistematico per la definizione dell’architettura utilizzando componenti nuovi e/o preesistenti. Modellizzazione Visuali Questo processo mostra come modellizzare in maniera visuale il progetto software per catturare la struttura e il comportamento delle varie componenti. L’astrazione visuale aiuta a comunicare differenti aspetti del progetto, come gli elementi combacino nel sistema, accertare che i blocchi siano in linea con il codice, mantenere la consistenza tra il design e l’implementazione e favorisce la comunicazione disambigua con il cliente. Lo standard industriale Unified Modeling Language è il fondamento per una modellizzazione visuale di successo. Lo UML è uno strumento per analisti e progettisti di sistemi orientati agli oggetti che consente di modellare, rappresentare e documentare sistemi 27
  29. 29. software. Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim Rumbaugh e Ivar Jacobson (detti "i tre amigos") sotto l'egida dello OMG, che tuttora gestisce lo standard di UML. Questo linguaggio di modellazione visuale è un insieme di elementi e di regole, di specifica formale ed offre un notevole vantaggio; infatti anche i progettisti e gli analisti di sistemi informativi utilizzano figure e diagrammi per visualizzare il risultato del loro lavoro: il sistema software. Durante le fasi di analisi e progettazione vengono generati dei modelli che consentono di identificare e separare le caratteristiche di un sistema reale. Il progettista dovrà quindi decidere quali caratteristiche sono rilevanti per il sistema che sta costruendo, inserirle e definire le relazioni tra gli elementi del modello. Ciò avviene anche se il tipo di prodotto finale che risulta dalla progettazione non è necessariamente visuale. Il Rational Unified Process quindi è uno schema generale di un processo, da adattare alle diverse tipologie di progetto, esso si articola in una serie di iterazioni con lo scopo di ridurre progressivamente i rischi, a partire da quelli principali (es. incomprensioni sui requisiti, incertezze implementazione). In ogni iterazione si svolgono, in misura e in percentuali diverse, le tipiche attività di sviluppo (es. gestione dei requisiti, design, implementazione, test) adottando così un modello incrementale che si svolge attraverso la realizzazione ed eventualmente il rilascio dell’applicazione in modo progressivo guidata però dai casi d’uso e dalle priorità architetturali. La definizione dell’architettura applicativa e tecnologica costituisce il fondamento tecnico dell’applicazione e del progetto, ed il consolidamento della stessa avviene solo quando si è certi della sua fattibilità tecnica. Fino a quando l’architettura non è consolidata non esistono elementi sufficienti per 28
  30. 30. determinare i tempi, i costi e i rischi dell’intervento progettuale con la precisione necessaria per la stipulazione di un contratto. 3.1 Le fasi del RUP Nel RUP, il ciclo di vita di un processo software viene suddiviso in cicli di sviluppo, a loro volta scomposti in fasi. Le fasi previste sono: • Inception Phase • Elaboration Phase • Construction Phase • Transition Phase Ogni fase si conclude con una milestone per indicare il raggiungimento di obiettivi stabiliti in fase di definizione del progetto stesso. Inception Phase Questa fase si può considerare come una particolare elaborazione e precisazione del concetto generale di analisi di fattibilità. Lo scopo principale è quello di delineare nel modo più accurato possibile il business case, ovvero comprendere il tipo di mercato al quale il progetto afferisce e identificare gli elementi importanti affinché esso conduca a un successo commerciale. Fra gli strumenti utilizzati ci sono un modello dei casi d'uso, la pianificazione iniziale del progetto, la valutazione dei rischi, una definizione grossolana dei requisiti e la identificazione delle interazioni ad alto livello. Alla fine di questa fase è presente la prima milestone maggiore del progetto, detta "Lifecycle Objective Milestone". I criteri di valutazione per la Inception Phase sono: 29
  31. 31. • Coincidenza del rapporto definizione dello scopo e costo stimato con le aspettative del cliente; • Comprensione e definizione dei requisiti, evidenziato della corretta redazione degli use cases primari; • Credibilità dei costi stimati, priorità, rischi e organizzazione del processo di sviluppo; • Presenza di ampia ed accurata documentazione su ogni prototipo architetturale sviluppato; • Resoconto delle spese attuali e pianificazione delle future; Il progetto può essere abbandonato o ridimensionato in maniera considerevole nel caso non passi questa milestone. Elaboration Phase L’obiettivo principale di questa fase è analizzare il dominio del problema, stabilire una base architetturale, sviluppare un piano del progetto ed eliminare i fattori di rischio più elevato del progetto. Questa fase deve concludersi con il superamento di una milestone detta "Lifecycle Architecture Milestone". A questo scopo devono essere soddisfatti i seguenti criteri: • Sviluppato un modello dei casi d'uso completo all'80% • Fornire la descrizione dell'architettura del sistema • Sviluppata un'architettura eseguibile che dimostra il completamento degli use cases significativi • Eseguita una revisione del business case e dei rischi • Completata una pianificazione del progetto complessivo • Redazione di un manuale utente preliminare (opzionale) 30
  32. 32. Se il progetto non passa questa milestone, potrebbe ancora essere abbandonato, oppure dovrà essere revisionato. Al termine di questa fase si transita infatti in una situazione di rischio più elevato, in cui le modifiche all'impostazione del progetto saranno più difficili e dannose. Construction Phase Durante questa fase, tutte le componenti vengono sviluppate ed integrate al prodotto, e infine vengono testate. Nella construction phase è, in un certo senso, un processo manifatturiero in cui l’enfasi viene dedicata alla distribuzione, controllo e gestione delle risorse per ottimizzare i costi e massimizzare la qualità. Molti progetti sono sufficientemente estesi per permettere una organizzazione parallela nella realizzazioni di alcune componenti. Queste attività parallele possono accelerare significativamente il rilascio ma incrementa notevolmente la complessità di gestione delle risorse e sincronizzazione dei workflow. Al termine della Construction Phase c’è la così denominata “Initial Operational Capability Milestone”, essa deve determinare se quello che è stato prodotto può considerarsi operativo senza esporre l’intero progetto a qualche rischio. Gli output essenziali di questa fase sono: • Il prodotto software pianificato da realizzare funzionante ed integrato sulla piattaforma adeguata • Il manuale utente • Una descrizione della release corrente Transistion Phase Questa fase si propone di attuare la transizione del prodotto sviluppato al cliente, è facilmente intuibile che una volta installato si renderanno necessari degli interventi correttivi o sviluppativi che richiederanno delle 31
  33. 33. nuove release. La Transition Phase si introduce quando lo sviluppo iterativo si porta ad un punto sufficiente per permettere il rilascio al cliente, i tipici requisiti per fare ciò sono che il libello di qualità del sottosistema completato sia accettabile e che la documentazione utente sia disponibile. In questo modo la transizione del prodotto al cliente porterà un risultato positivo per entrambe le parti, permettendo ad esempio di validare il nuovo sistema e di iniziare a formare il personale. Con la “Production Release Milestone” si vuole valutare se effettivamente il cliente è soddisfatto di ciò che gli si propone e se il dispendio registrato di risorse contro quello programmato è accettabile. A questo punto, se gli obiettivi sono stati raggiunti è possibile iniziare un altro ciclo di sviluppo, in alcuni casi questa milestone coincide con la fine della inception phase del ciclo successivo. 3.2 Aspetti statici del RUP Il meta modello applicato dal RUP per descrivere e controllare un processo utilizza quattro concetti cosiddetti "statici", ovvero che sono definiti nello stesso modo per tutti i processi: • Worker Un ruolo identifica un certo insieme di responsabilità attribuite a un certo insieme di partecipanti al progetto (I ruoli rispondono alla domanda chi?); • Artifact Gli artefatti sono il prodotto delle attività del processo; includono documenti, modelli, componenti software e via dicendo (Gli artefatti rispondono alla domanda cosa?); 32
  34. 34. • Workflow Un workflow è una sequenza di attività che producono un risultato in un tempo osservabile (I workflow rispondono alla domanda quando?); • Attività Le attività sono i compiti specifici portati a termine dai partecipanti del progetto (Le attività rispondono alla domanda come?); 33
  35. 35. 4. Identificazione delle problematiche di progetto 4.1 EURIDICE Il progetto Euridice, è un progetto cofinanziato dalla Commissione Europea, che si prefigge la realizzazione del concetto di "Cargo Intelligente" come veicolo di ottimizzazione del settore logistico. E’ un Integrated Project con un budget di circa 14 M€ e un partenariato di 22 partner provenienti da 9 paesi europei che include aziende leader nelle tecnologie software, mobile, wireless e RFID, rinominati centri di ricerca, operatori logistici, istituzioni e utenti finali. L’obiettivo del progetto è la creazione di una architettura e di applicazioni pilota atte a verificarne la validità e l’usabilità nel mercato dei trasporti europei. Potendo installare dispositivi con una certa capacità elaborativa direttamente sulla merce, questa potrebbe essere in grado di riconoscere il contesto in cui si trova, prendere decisioni e segnalare eventuali anomalie, questo in estrema sintesi è il “Cargo Intelligente” che può quindi diventare un attore primario nei processi di trasporto e delivery, e fornire informazioni in tempo reale dettagliate ed affidabili al sistema centrale. Il continuo dialogo fra dispositivi di diverso livello automatizza procedure oggi affidate all’utente umano e migliora le tempistiche e l’efficienza di molte fasi dipendenti dai trasporti: velocità di consegna, carico e scarico, programmazione della produzione in funzione degli arrivi dei semilavorati, ottimizzazione visti doganali e controlli, tracciabilità in tempo utile della posizione della merce e dei veicoli, programmazione del percorso 34
  36. 36. centralizzata, disposizione di informazioni sullo stato della merce in tempo reale e così via. Risulta immediato realizzare le potenzialità di tale progetto e al tempo stesso risulta evidente che le difficoltà che si potranno presentare non sono poche. Viene generalizzato Euridice ad un progetto generico portandosi così in una situazione favorevole ad un’analisi delle possibili problematiche di un progetto di questo tipo. Ci si pone quindi in uno scenario in cui un consorzio di aziende si associano per sviluppare un progetto di ricerca europeo. Tali aziende sono distribuite in vari paesi e non sono specializzate negli stessi settori. Partendo da questi presupposti si procede all’identificazione delle problematiche. 35
  37. 37. 4.2 Analisi dello scenario Prendendo in considerazione il sopra descritto scenario ci si può facilmente rendere conto delle enormi implicazioni gestionali di un simile progetto, anche se fosse sviluppato da una singola azienda. Per iniziare ad analizzarne le problematiche infatti porremo proprio questa ipotesi, ovvero che solo una azienda si occupi del suo sviluppo per poi ampliare la panoramica. Nonostante ci si ponga in un ambiente molto semplificato per analizzare l’impatto del problema, ci si rende immediatamente conto che essendo preso in esame un progetto di ricerca e sviluppo su un tema commissionato, lo scopo non sarà definito sufficientemente a priori. Proprio per questo sarebbe saggio stimare con la dovuta accortezza la durata preventiva delle fasi del progetto, soprattutto quelle iniziali di analisi, dilatandone leggermente i tempi stimati per permettere di poter far fronte in maniera meno incisiva a ridefinizioni dovute a sviluppi e/o a funzioni introdotte in fasi successive. 36
  38. 38. Dato che i “progetti di ricerca” finanziati dall’Unione Europea sono indetti tramite un concorso fra gli sviluppatori, al suo interno saranno proposte applicazioni tecnologiche innovative e soprattutto un utilizzo di prodotti hardware e software del tutto nuovi. Proprio questi potrebbero rivelarsi una lama a doppio taglio, aumentando sicuramente il livello del progetto di ricerca ma andando ad incidere significativamente sull’onere da sostenere per il suo sviluppo. Alcune tecnologie nascenti infatti sono così nuove da non esser state ancora assimilate, o nemmeno conosciute, all’interno dell’azienda ove il costo diretto di produzione di un progetto dipende largamente dalla preparazione e dalla “cultura” dei dipendenti. Inoltre capita frequentemente che i nuovi prodotti ancora mai utilizzati realmente su vasta scala o all’interno di un progetto industriale sufficientemente elaborato per cercare di sfruttarne tutte le peculiarità, siano affetti da vari errori di funzionamento nelle versioni distribuite e necessitino quindi di una vasta comunicazione fra azienda sviluppatrice e casa madre per la correzione. Queste considerazioni non sono necessariamente un danno per il progetto ma sicuramente ne aumentano il costo e rendono più ardua la stima dei tempi necessari alle varie fasi del progetto. Spostandoci ora in una fase un po’ più avanzata, si renderà importante definire degli standard per l’organizzazione dei contenuti e della forma dei deliverables delle varie fasi, essendo un progetto internazionale, essi costituiranno le tappe e la prova dei progressi del lavoro non solo ai Project Manager che lo dirigeranno ma probabilmente anche ad esaminatori dell’Unione Europea ed ai responsabili delle aziende affiliate per il progetto. Proprio con questi soggetti infatti l’azienda dovrà periodicamente relazionarsi per ottenere i requisiti e i chiarimenti necessari al corretto proseguimento della vita del progetto. Per fare ciò infatti sarà necessario del 37
  39. 39. personale qualificato sia per quanto riguarda il colloquio con gli altri soggetti esterni, sia per quanto riguarda la conoscenza dei vari paesi ove risiedono le aziende collaboratrici. Infatti una problematica da sempre riscontrata nella fase di analisi è l’omissione di dettagli di un certo peso per una corretta impostazione del progetto poiché il soggetto che deve descrivere il processo li ritiene così scontati che dimentica di farne menzione nei colloqui. Tutto ciò è ovviamente accentuato dal fatto che l’azienda sviluppatrice e quella collaboratrice possono non essere connazionali andando così a limitare significativamente quel margine di conoscenza che permette solitamente all’analista, tramite domande mirate e l’esperienza, di identificare ed eliminare le sopradette omissioni. Incisive saranno quindi le competenze linguistiche e culturali per potersi avvalere efficacemente delle collaborazioni con aziende estere. Bisogna ricordare che nonostante la tecnologia moderna ci permetta di essere in contatto ventiquattro ore su ventiquattro con tutto il mondo, certe questioni sia per un fatto diplomatico che da un punto di vista pratico sarebbero da risolvere di persona; il che risulta problematico data la possibile lontananza geografica con determinati soggetti coinvolti nel progetto. Per poter sviluppare alla massima efficienza un progetto sarebbe necessario poter utilizzare, di volta in volta, la metodologia più congeniale ed adattarla ad esso. In realtà ogni azienda sviluppatrice di software ha una sua metodologia affermata che è stata negli anni assorbita dal personale, con precisi modi di lavorare che personalizza l’azienda sia al suo interno che dall’esterno. Questo metodo non è ovviamente rigido ma viene adattato, con flessibilità propria di ogni azienda, al progetto in corso per permettere una ottimizzazione dei costi all’azienda. Quindi è presumibile che nonostante il progetto sia di ricerca, il suo cammino sarà comunque aderente al modus operandi dell’azienda sviluppatrice. 38
  40. 40. L’attenzione ad altre procedure produttive di carattere più scontato come definizione del cammino critico delle varie sottofasi del progetto, l’ottimizzazione del tempo tramite una messa in parallelo delle stesse formando diversi workgroup e loro controllo tramite milestones; si daranno, per il momento, per pienamente efficienti ed assimilate dall’azienda sviluppatrice. La stessa funzionalità dei deliverables per le fasi successive però non è del tutto scontata dato che si è dovuto apporvi alcune modifiche nella struttura e soprattutto nella lingua utilizzata per adoperarli, come menzionato in precedenza, in ambito europeo. 4.3 Approfondimento Conclusasi la prima fase di analisi dell’impatto del problema ora si è pronti ad approfondire la struttura dell’azienda sviluppatrice. Come premesso nella descrizione dello scenario la realizzazione di tale progetto non è affidata ad un’ unica azienda ma ad un insieme di aziende software affiliate per tale scopo e da alcune aziende collaboratrici, che saranno poi i primi utilizzatori dei piloti del progetto. La distribuzione in diversi paesi di tali soggetti implica un notevole incremento della difficoltà di coordinazione, essa già problematica di per se dato il numero delle aziende coinvolte. Quindi si proceda ad ampliare il soggetto analizzato in precedenza “Azienda Sviluppatrice” considerando però invariato il rapporto fra essa e gli altri soggetti come l’Unione Europea e l’approccio alle nuove tecnologie. 39
  41. 41. Si può immediatamente identificare un vantaggio del nuovo diagramma, il problema menzionato in precedenza sui problemi degli analisti nel colloquiare con aziende non connazionali e sulle relative problematiche dovute alla lontananza si possono affievolire o risolvere grazie alla disposizione di diversi partner dislocati in differenti paesi europei. Però analizzando meglio la situazione ci si rende conto che il problema di comunicazione si è spostato all’interno del gruppo sviluppatore data la varietà di partner presenti. Questo non dovrebbe costituire una grave complicanza rispetto alla situazione analizzata in precedenza poiché il problema di comunicazione già esposto con le aziende si è affievolito e la standardizzazione e l’internalizzazione dei documenti interni all’azienda (deliverables) era già stata preventivata seppure per altre cause. Lungi dall’essere risolto il problema di composizione eterogenea del gruppo sviluppatore che introdurrà sicuramente altre problematiche, per lo meno per quanto riguarda la necessità di ridefinire i documenti interni si può dire che non ne aumenta la complessità già preventivata. 40
  42. 42. Si pensi ora alla composizione dei workgroup in un’azienda sviluppatrice. Per favorire la produttività si tende ad aggregare gli elementi più adatti ad un certo compito nello stesso gruppo per poi affidargli il ruolo migliore alle loro capacità. Se questo ragionamento si applica anche per una azienda sviluppatrice risulta palese che si potrà avere dei gruppi di lavoro eterogenei trasportando tutte le problematiche precedentemente sollevate a livello aziendale anche negli stessi workgroup. La risoluzione di tali problemi risulta concorde con i ragionamenti introdotti in precedenza, ovvero la standardizzazione degli artefatti e una collaborazione aperta mediante molti dei canali di comunicazione che la tecnologia moderna mette a disposizione. Riferendosi alla struttura che abbiamo dato per scontata nella prima analisi ci si deve necessariamente rende conto che ognuno dei partner coinvolti avrà una sua metodologia affermata e operativa al suo interno. Questa non necessariamente sarà simile a quella di un altro qualsiasi partner. Generalmente la differente etnia provoca una grossa differenza del modo di pensare, della cultura e delle conoscenze già su un singolo individuo quindi non è così astratto preventivare, pensando a livello aziendale, di trovarsi di fronte ad almeno una differente metodologia per paese di dislocazione dei partner. La problematica legata al linguaggio ora è amplificata dal numero di soggetti coinvolti. Scendendo nel dettaglio delle aziende infatti, nonostante la percentuale di personale con una conoscenza dell’inglese alquanto limitata sia molto bassa in una singola azienda, ci si accorge che deve per forza contare un numero congruo di persone se applicata all’intero gruppo di sviluppo. Questo fatto può portare a difficoltà di alcuni workgroup di creare materiale standard per le fasi successive. Il riscontrarsi di problemi comunicazione è altrettanto plausibile ovviamente, nel caso sia necessario 41
  43. 43. colloquiare con altri workgroup non connazionali assegnati a sottofasi relazionate ad essi. Naturalmente non è un problema di primaria importanza poiché con un minimo di collaborazione interna aziendale, un intelligente creazione dei workgroup e assegnazione ai vari compiti la situazione è arginabile. Comunque però implicherà una maggiore attenzione in certe fasi e una inadattabilità di una certa percentuale di personale a determinati compiti, il che porta ovviamente ad un probabile aumento di tempo e denaro impiegato nell’organizzazione del lavoro. Parlando ora di suddivisione del lavoro, per quanto riguarda una distribuzione delle fasi lavorative ad un numero elevato di soggetti di devono ricordare le basi della ottimizzazione del lavoro. Infatti non è detto che più persone si impiegano allo stesso progetto, maggiore sarà la produttività del team; poiché superata una certa soglia si comincia a spendere più tempo per la comunicazione interna che per lo sviluppo in senso stretto. Tutto questo senza considerare che ogni soggetto coinvolto ha bisogno di un livello specifico di conoscenza dell’avanzamento del progetto generale, portando così ad aumentare i tempi necessari alla comunicazione interna delle informazioni. Questo discorso è si può applicare sia al livello di dettaglio esposto che riferito al numero di workgroup operativi in un progetto. Spezzettando in troppe parti il lavoro si creano, a parte le problematiche generiche di comunicazione appena accennate, delle dipendenze forzate dal lavoro altrui che non sempre permettono lo svolgersi del lavoro in parallelo delle attività. Anzi esse probabilmente tendono a portare scompiglio, ritardi ed a periodi di improduttività di alcuni dei workgroup. Senza considerare che queste conseguenze si possono ripercuotere ed amplificare notevolmente nel caso le dipendenze intercorrano fra gruppi di lavoro appartenenti a differenti partner (non connazionali). Per questo è assolutamente necessario imporre uno standard anche sulle piccole fasi e non solo sui deliverables finali delle varie attività. 42
  44. 44. Deve esserci omogeneità nei tool utilizzati per le varie attività e se proprio ciò non risulta possibile a livello globale, almeno fra quelle attività che sono in relazione di dipendenza diretta. Essenziale per un progetto di queste dimensioni e per la quantità di soggetti coinvolti, è realizzare che ogni partner è una azienda a se stante che, anche se sta collaborando con le altre per il progetto, tenderà a dimostrare un suo orgoglio aziendale, per così dire. Questa problematica non è banale perché la base della collaborazione redditizia è la non competitività dei partner per l’assegnazione dei compiti (la competitività non è necessariamente dannosa, anzi fa bene in molti altri ambiti fungendo da sprone per migliorare se stessi, la qualità e la velocità del lavoro). Per poter comprendere appieno le implicazioni del problema si deve analizzare come avviene l’assegnazione dei compiti in una struttura così complessa, come al solito partiamo da un livello generale e molto semplificato del problema. Al fine di realizzare al meglio un progetto, la logica imporrebbe di assegnare le fasi più critiche ai soggetti migliori e le fasi restanti ai gruppi qualificati in ordine di importanza delle varie attività, invece il problema andrebbe affrontato da un punto di vista inverso. Siccome la resistenza di un oggetto è diretta funzione dell’anello più debole, sarebbe meglio assegnare ad ogni gruppo l’attività che lui può svolgere meglio rispetto tutte le altre attività restanti. Applicando questo ragionamento però si viene a creare la problematica accennata in precedenza. Se ogni team viene assegnato in questa ottica non è detto che a certe aziende arrivino incarichi appaganti o che dimostrino credibilità ed di importanza nella loro partecipazione al progetto. Bisogna assolutamente sfasare questa sensazione mettendo in chiaro che ogni partner è di egual importanza, anche se non di egual peso sul progetto. L’obiettivo del gruppo di sviluppo non è dimostrare quale sia la gerarchia di qualità delle aziende coinvolte, ma realizzare il prodotto meglio 43
  45. 45. possibile sfruttando tutti i partner coinvolti nel modo migliore per il fine collettivo. La risoluzione ideale per render appagati tutti del proprio operato e della propria appartenenza al gruppo di sviluppo sarebbe una assegnazione a rotazione delle attività di maggiore importanza nelle varie iterazioni del progetto. Questo sarebbe nuovamente in contraddizione con il metodo di assegnazione suggerito. Come accade molto spesso nella pratica, si dimostra necessario considerare caso per caso ed applicare il punto di incontro fra i vari metodi produttivi e diplomatici per il bene della stabilità comune. La quantità di problematiche sollevate semplicemente per strutturare il lavoro necessario per l’effettiva realizzazione del progetto suggerisce che probabilmente la dichiarazione della tempistica di progetto si rivelerà inadeguata. Quasi ogni problema che è stato analizzato, come danno collaterale, apportava un aumento di tempo e del costo del lavoro e ci sono probabilità non nulle, proprio come in qualsiasi altro progetto, di incappare in errori non direttamente dipendenti dalle considerazioni da effettuate. La possibilità di un ritardo nei tempi è molto alta e esso non sarà da riferire al termine edotto dall’Unione Europea ma da quello effettivo stimato del progetto conclusasi completamente la fase di analisi. 44
  46. 46. 4.4 Riassumendo In seguito all’analisi appena presentata, risultano essenziali molte procedure nel complesso del progetto: Nel definire il progetto bisogna essere in grado di quantificare e valutare correttamente l’impatto di tecnologie particolari sul processo di sviluppo. Iniziare a formare il personale con largo anticipo e non durante il progetto sia ai fini linguistici che tecnologici necessari per una ottimale adeguatezza della forza lavoro ai compiti imminenti. A fine di stimare la tempistica di progetto è necessario collezionare informazioni dettagliate non solo sulle aziende coinvolte, ma su tutti i dipendenti che verranno impiegati al progetto e sui workgroup in cui operano solitamente, naturalmente ad un livello di aggregazione dei dati adeguato (risulta ovvio che per il fine preposto non costituisce nessuna utilità sapere il nome o l’indirizzo del soggetto in questione ma solamente le sue abilità, conoscenze ed attitudini lavorative). Definire in modo preciso e non ambiguo le relazioni (e mediante che canali) che intercorrono fra il gruppo di sviluppo e i soggetti esterni, come i valutatori dell’Unione Europea e i collaboratori delle aziende esterne. Importante definire inoltre le relazioni per la comunicazione fra i vari partner, creando molti canali di comunicazione e ben funzionanti assegnando ad essi personale adatto e qualificato. Siccome il progetto in esame è un progetto di ricerca risulta adeguato dilatare opportunamente le tempistiche di alcune fasi e preventivare almeno una iterazione aggiuntiva per eventuali evoluzioni delle funzionalità e degli scopi del progetto. Il pessimismo nella stima è caratteristica di capacità 45
  47. 47. realistiche dell’azienda e diminuisce il rischio di disillusioni per il protrarsi del termine di sviluppo. Inoltre nel qual caso tutto procedesse al meglio ci si troverebbe ad aver ultimato il compito prima della scadenza dichiarata lasciando tempo per rifiniture successive del prodotto che aumentano la soddisfazione finale del cliente ma che, nel caso di scadenze troppo brevi, non vengono attuate per la scarsa disponibilità di tempo. Definire di comune accordo fra i partner degli standard interni per la metodologia di sviluppo, la struttura e il contenuto dei deliverables, la frequenza e la profondità dei controlli periodici di avanzamento del lavoro; ma soprattutto definire ad un livello sufficiente di dettaglio le sottofasi della Analisi e della Progettazione indicandone subito le dipendenze al fine di evitare parallelismi impossibili. L’ideale sarebbe ottenere un diagramma di Gantt funzionale delle fasi di analisi e progettazione includendo, come precedentemente menzionato, le dilazioni opportune dei tempi e alcune fasi riparatorie per fornire un margine accettabile alle incertezze non meglio quantificabili ad inizio del progetto. Questo diagramma ovviamente non può essere assolutamente definitivo ma deve aiutare a programmare il lavoro evolvendo assieme alla precisa definizione del progetto. 46
  48. 48. 5. Approccio Lo sviluppo effettivo di un progetto di ricerca internazionale e collaborativo sarà estremamente complesso, specialmente dal punto di vista coordinativo. Come è stato visto dall’analisi delle problematiche principali riscontrabili in questo tipo di progetto, la maggior parte delle difficoltà saranno per l’appunto dovute alla distribuzione e al controllo dei compiti. I dettagli dei ponti di collegamento possibili fra le varie aziende ed eventuali raccomandazioni su essi sono di scarsa importanza dal punto di vista della metodologia a cui bisognerà ricorrere. Questo poiché il come si collabora influisce parzialmente sulle fasi da intraprendere e dagli artefatti da realizzare, al più implicherà delle restrizioni sulla lingua utilizzata o sulle tempistiche di produzione. Lo stesso discorso è applicabile anche alle problematiche di stima dei tempi di progetto, il fatto che il tempo previsto subisca dei dilatamenti dovuti alla struttura dell’azienda sviluppatrice non sarà direttamente imputabile alla metodologia applicata bensì alla complessità della struttura. Infatti si può affermare che, qualsiasi sia il metodo di lavoro scelto, la probabilità di un ritardo è comunque stabile e principalmente dipendente dall’organizzazione su cui viene applicato tale metodo. L’unica problematica rimanente è quindi la presenza di differenti competenze distribuite all’interno delle varie aziende affiliate e dei gruppi di lavoro. Ciò porta ad un bivio di entità notevole, o si opera una pesante istruzione del personale per eliminare il problema o si attua una modifica della metodologia al fine di poter essere approcciata anche da chi ha scarse nozioni in tale materia. 47
  49. 49. La situazione ideale prevedrebbe ovviamente il colmare le lacune del personale, investendo così sui propri dipendenti ed aumentando il valore della propria azienda. Ma una manovra del genere nella pratica è estremamente difficile, specialmente data la natura internazionale del progetto in esame. D’altro canto un livellamento troppo drastico di una qualsiasi metodologia otterrebbe sì un facile assorbimento dal personale non competente, ma comporterebbe senza ombra di dubbio degli effetti negativi enormi sul prodotto finale. A seguito di queste ultime considerazioni si deve prendere atto che l’una o l’altra via non sono percorribili nella realtà di un progetto internazionale, a parte rari casi. In generale quindi l’approccio applicabile consisterebbe in uno snellimento di una metodologia molto versatile, al fine di poter effettuare con un buon livello di dettaglio le fasi principali previo breve istruzione del personale. Alcune fasi o artefatti delle metodologie di progetto infatti non sono particolarmente complesse e un dipendente medio può riuscire a svolgerle con successo senza particolari preparazioni, ma con sicuramente l’ausilio di una buona documentazione. Data la necessità di flessibilità e di segmentazione necessarie ad una metodologia per poter essere snellita in modo proficuo al fine preposto, si prenderà in considerazione l’approccio iterativo ed incrementale messo a disposizione dal Rational Unified Process. Esso infatti risulta essere un metodo incredibilmente ampio e versatile, proprio per sua costruzione, e quindi perfettamente aderente al problema in esame. L’obiettivo quindi è proprio l’identificazione di una fetta del RUP che calzi con il progetto in lavoro, ovvero trovare una buona guida metodologica per permettere una buona organizzazione e resa lavorativa. 48
  50. 50. Inserendo questo lavoro in un progetto di ricerca già avviato da diversi anni come Euridice, risulta difficoltoso estendere questa procedura sull’intera metodologia. Inoltre un tale compito risulterebbe di difficoltà ben più elevata e sicuramente l’aprirsi di una discussione generale sullo snellimento del RUP in tutte le sue fasi per l’applicazione a progetti del tipo sopraesposto comporterebbe discussioni pressoché infinite nell’ambito analistico. Rifacendosi alle spiegazioni del metodo menzionate nel capitolo apposito presentiamo a seguire una figura esplicativa della struttura di un’iterazione prevista dal metodo RUP applicata ad Euridice. Come è visibile nella figura, le fasi iniziali sono state scomposte e dettagliate per fornire maggiore dettaglio. Inoltre si può osservare che sono state utilizzate le nomenclature tipiche dell’Unified Modeling Language. Per la fase di analisi si è applicato ovviamente la Use Case Analysis o Analisi per casi d’uso. 49
  51. 51. Lo sviluppo di Euridice era per l’appunto giunto alla conclusione della fase di analisi. Sarà ora necessario cimentarsi nella fase di progettazione, che nel caso specifico includerà la realizzazione dei casi d’uso definiti nella fase di analisi. Lo scopo è quindi quello di identificare il numero minimo di artefatti necessari ad una completa progettazione, seguendo il metodo della realizzazione dei casi d’uso facendo riferimento al linguaggio UML. 50
  52. 52. 5.1 Guida Metodologica alla progettazione Vengono di seguito descritti brevemente i fondamenti necessari alla comprensione degli artefatti risultanti dalla fase di analisi per poter poi proseguire correttamente nella progettazione. Essendo la realizzazione dei casi d’uso tramite diagrammi UML un approccio visuale alla progettazione degli stessi, esiste un vasto numero di modi per procedere. Inevitabilmente lavorando in modo visuale si può cogliere il sistema in esame da un solo punto di vista, quindi è scontato che saranno necessari vari diagrammi per una rappresentazione completa del caso. Verrà reso necessario e quindi descritto il minor numero possibile di diagrammi cercando comunque di mantenere una completa definizione nella realizzazione del caso d’uso. Inoltre il metodo UML mette talvolta a disposizione più diagrammi che rappresentano lo stesso concetto ma in maniere differenti. In caso tale punto di vista sia rivesta fondamentale importanza nella definizione della UCR allora si propenderà per quel diagramma più semplicemente sviluppabile. Use Case I casi d’uso costituiscono un ottimo strumento per ottenere una visione d’insieme del sistema che si sta analizzando, rappresentano un comportamento dal punto di vista dell’utilizzatore del sistema e sono finalizzati a modellare il dialogo tra utilizzatore e sistema. Per questo si dice che i casi d’uso forniscono una visione del progetto. Infatti essi: • descrivono l’interazione fra attori e sistema, non la logica interna della funzione; 51
  53. 53. • sono espressi in linguaggio naturale e sono comprensibili anche a lettori non tecnici; • descrivendo i casi d’uso si definiscono i requisiti funzionali di progetto; • possono essere un valido ausilio nel dialogo con l’utente ed in generale con esponenti non tecnici; L’attore è un’entità esterna al sistema, può essere umano o un altro sistema, che fornisce lo stimolo a cui esso risponde con specifici comportamenti. Tutto ciò è definito nella Analisi dei casi d’uso che si conclude quando la maggior parte dei casi d’uso è stata descritta. Per ognuno di essi devono essere stati definiti: precondizioni, attori coinvolti, obiettivi, svolgimento principale degli eventi dello scenario, svolgimenti alternativi e post condizioni. Nella fase di design si dovrà prendere in considerazione quindi questi casi d’uso e delle loro descrizioni, che sono il risultato della fase di analisi, ed iniziare a definirli prendendo in considerazione anche i requisiti tecnologici che vengono scelti per il progetto. 52
  54. 54. Lo scopo essenziale è chiarire come gli attori interloquiscano con i vari casi d’uso e di che dati abbiamo effettivamente bisogno per operare. Allo scopo di fare ciò si tenderà per un approccio visuale utilizzando lo standard UML anche se sarà necessario allegare comunque una buona documentazione scritta. Use Case Realization La realizzazione dei casi d’uso, o UCR, rappresenta la prospettiva della progettazione dei casi d’uso derivati dalla fase di analisi. Ogni artefatto prodotto durante la fase di design andrebbe associato al caso d’uso da esso analizzato, ma proprio per poter disaccoppiare la fase di analisi da quella di design si introduce il concetto di UCR. Siccome nella fase di design si deve tener conto dei vincoli tecnologici si può intuire che un singolo caso d’uso può essere progettato in più modi diversi. Quindi possono esistere diversi UCR associati allo stesso caso d’uso, e siccome gli artefatti della fase di design vengono di conseguenza associati allo specifico UCR si facilità la gestione separata degli use case realizzati nella fase di analisi dalla loro realizzazione. Questa strategia è particolarmente indicata per progetti di grandi dimensione ove lo stesso caso d’uso può essere progettato in modo diverso per la necessità del suo utilizzo su diverse piattaforme. Per rappresentare tutto ciò si utilizza un diagramma della realizzazione dei casi d’uso sarà semplicemente sufficiente trattare ogni UCR come una generalizzazione dei caso d’uso con una notazione del tipo UC UCR come è 53
  55. 55. visibile nella figura successiva. Per ogni UCR è necessario identificare gli oggetti che partecipano alla composizione del caso d’uso. Al fine di descrivere completamente un caso d’uso il linguaggio UML mette a disposizione una grande varietà di diagrammi. Lo scopo di questa fase è di identificare per ogni UCR tutti gli elementi statici e dinamici coinvolti. Gli elementi statici di un oggetto sono i dati persistenti di cui necessita per operare e le relazioni che lo legano ad altri oggetti. Gli elementi dinamici invece possono essere descritti come le modalità di collaborazione fra oggetti per realizzare una determinata funzione. Evidenziamo anzitutto tre tipi di oggetti e loro notazione in UML: • Entità che rappresentano i dati persistenti di cui necessita lo UC • Interfacce sono oggetti necessari per il corretto dialogo con elementi esterni (input/output) • Controlli che rappresentano la logica di business del sistema Per ogni use case realization si dovranno evidenziare almeno tre oggetti: un’Entità, un’interfaccia e un controllo. 54
  56. 56. La figura seguente mostra un diagramma per la realizzazione di un caso d’uso “Receive Deposit Item”, si può notare che il livello di descrizione è molto alto e serve quindi solo ad identificare gli oggetti coinvolti. Una classe e i suoi oggetti possono spesso partecipare a svariate realizzazioni differenti di un caso d’uso. Definendo gli UCR probabilmente si nota che alcuni oggetti vengono impiegati in un numero elevato di casi. È consigliato dunque controllare come un oggetto debba essere realmente strutturato per favorirne la riusabilità attraverso i vari UCR. I diagrammi più importanti per la corretta realizzazione dei casi d’uso sono i seguenti: • Sequence Diagram : descrive un preciso scenario di un caso d’uso seguendone la linea temporale • Class Diagram : evidenzia i contenuti statici del caso d’uso • State Diagram : analizza il comportamento e la vita di un oggetto attraverso tutti i casi d’uso che lo utilizzano Nelle descrizioni seguenti verranno fornite delle semplici esemplificazioni di ogni tipo di diagramma per permetterne una più rapida comprensione. Inoltre nel Capitolo 6 verranno applicati praticamente ad un 55
  57. 57. caso d’uso di Euridice fornendo un ulteriore approfondimento al metodi di sviluppo dei sopra esposti diagrammi. 56
  58. 58. Diagrammi di Sequenza Il diagramma di sequenza rientra negli Iteration Diagrams. L’obiettivo di questa categoria di diagrammi è descrivere come un gruppo di oggetti cooperi per realizzare una funzione. Nello specifico del Sequence diagram, esso analizza un singolo svolgimento del caso d’uso (principale o alternativo) e il modo in cui viene svolto dalla collaborazione tra un insieme di oggetti, specificando la sequenza dei messaggi scambiati tra gli stessi. Possono essere evidenziati nodi decisionali e/o iterazioni. Questo tipo di diagramma viene anche detto di interazione in quanto mostra le interazioni tra oggetti del sistema, modella il comportamento dinamico del sistema ed evidenzia in particolare l’ordine temporale dello scambio di messaggi. Tutti i tipi di oggetto che vengono richiamati per svolgere l’interazione devono essere rappresentati da un riquadro nella parte superiore del diagramma. Le linee verticali rappresentano la linea della vita, o lifeline, dell’oggetto suo proprietario nell’arco di durata dell’interazione. Per mostrare quando un oggetto è attivo si include un riquadro di attivazione che viene riportato sulla sua lifeline. Quando un oggetto viene eliminato si appone una “X” sul punto temporalmente corretto e si interrompe la sua lifeline. Tutti i messaggi scambiati fra due oggetti durante la loro vita sono rappresentati da una freccia del tipo sorgente→destinatario e per ognuna di loro deve essere indicato almeno il nome di tale messaggio. Possono poi essere presenti messaggi prodotti dallo stesso oggetto che ne è il destinatario, essi si chiamano self-call. Importante sottolineare che nonostante la notazione 57
  59. 59. del messaggio, esso rappresenta la chiamata del sorgente ad una funzione del destinatario. I messaggi possono essere fondamentalmente di due tipi: • Sincrono l’emittente attende una risposta da parte del destinatario • Asincrono la risposta del ricevente, se è contemplata, potrà essere inviata in un qualsiasi momento successivo Se un messaggio ha una condizione per il suo invio si parla di messaggio condizionato e viene rappresentato tramite la specifica in parentesi quadre della sua condizione di invio. Questi messaggi vengono inviati quindi solo se al percorri mento temporale sulla lifeline dell’oggetto tale requisito è soddisfatto nel superamento del messaggio condizionato. Per indicare una iterazione di un messaggio si indica all’inizio del nome dello stesso un “ * ”, questo starà a significare che il messaggio in questione viene inviato più volte a più oggetti che però rientrano nella stessa categoria. 58
  60. 60. Generalmente si consiglia l’utilizzo di descrizioni testuali sulla parte sinistra del diagramma in tutti gli snodi principali per favorirne la leggibilità. Diagrammi delle Classi L’obiettivo dei diagrammi delle classi è visualizzare la parte statica del sistema rappresentando tutti gli oggetti, con i relativi attributi ed operazioni, che lo compongono. I collegamenti fra le classi rappresentano le associazioni che intercorrono fra esse. Tali associazioni possono essere corredate da un insieme di informazioni aggiuntive, per esempio relative alla molteplicità: • Uno-a-uno ad ogni occorrenza dell’oggetto A si può associare univocamente un’occorrenza dell’oggetto B e viceversa; (Es° dipendente↔matricola) • Uno-a-Molti per ogni occorrenza dell’oggetto B si può associarne una sola dell’oggetto A, ma per ognuna dell’oggetto A possono essercene un qualsiasi numero dell’oggetto B associate; (Es° Project Manager↔Progetto) • Molti-a-Molti: per ogni occorrenza dell’oggetto A si possono associare più occorrenze dell’oggetto B e viceversa; (Es° deliverable↔autore) È consigliato inserire una nomenclatura alle associazioni la dove ciò favorisca una maggiore leggibilità al diagramma. 59
  61. 61. Questi diagrammi utilizzano diversi concetti base del paradigma Object-Oriented ed altri correlati, fra questi se ne distingueranno per importanza quattro: Aggregazione, Composizione, Dipendenza e Generalizzazione. Ognuna delle sopra citate viene rappresentata mediante una particolare freccia che connette le due classi coinvolte. L’aggregazione è un particolare tipo di associazione che prevede una relazione fra delle entità autonome ed una che può essere definita solo dalla, per l’appunto, aggregazione di esse. Un buon esempio risulta un automobile: essa è composta dall’aggregazione di carrozzeria, motore, ruote e così via. La composizione è una relazione forte, può essere descritta in maniera similare all’aggregazione con la differenza che le entità che vengono messe in relazione di composizione seguono poi il ciclo di vita dell’istanza composta. Importante sottolineare che ogni oggetto può essere componente di un solo oggetto composto alla volta, il che differisce palesemente dall’esempio utilizzato in precedenza dell’automobile; ove per esempio un motore può essere montato su più tipi di auto. Una associazione di dipendenza sta ad indicare che un cambiamento di un attributo di una classe può andare richiedere modifiche negli attributi dell’altra, non necessariamente è implicato il viceversa. Alcune classi possono avere diverse varianti, ed ogni variante può avere diversi ruoli nel sistema. Per rendere tutto ciò rappresentabile in un diagramma delle classi si ricorre al concetto di generalizzazione. Essa si indica con una freccia del tipo sottoclasse sopraclasse come si può vedere nella figura seguente per LibroPregiato che specifica l’oggetto Libro. Il significato di tale azione e della notazione sono sufficientemente espliciti da non richiedere ulteriori dilunga menti in proposito. 60
  62. 62. Ogni oggetto viene rappresentato tramite un rettangolo suddiviso in tre scomparti, rispettivamente dedicati al nome della classe, agli attributi e alle operazioni. La visibilità di ogni attributo e di ogni operazione è specificata in UML attraverso l'uso di vari simboli: “-” visibilità privata: l'attributo è accessibile solo dall'interno della classe usando i propri metodi; “+” visibilità privata: l'attributo o il metodo è accessibile anche dall'esterno; “#” visibilità protetta: l'attributo o il metodo viene ereditato da tutte le classi da questa derivate. 61
  63. 63. Gli attributi devono essere indicati per nome con eventualmente il tipo e il valore di default seguendo il seguente standard: “ nome_visibile : tipo = valore_default ” Es° “ autore_anno_morte : data = Null ” L’elenco delle operazioni evidenziate in questo diagramma rappresenta l’insieme delle principali operazioni eseguibili all’interno dello UCR. Importante è specificare che non tutte le operazioni delle classi hanno lo stesso impatto sul sistema. Infatti risulta estremamente utile distinguere le semplici query (operazioni sugli attributi) da quelle operazioni che vanno a modificarli (operazioni di update). La sintassi completa per la descrizione delle operazioni in UML è la seguente: “ nome_visibile ( lista parametri ) : tipo_risultato_op {proprietà} “ Es° “ libro_pregiato_valorizza ( ) : float { } “ 62
  64. 64. Diagrammi di Stato È utile utilizzare il diagramma di stato per evidenziare come si comporta un oggetto attraverso più casi d’uso, esso infatti specifica tutto il ciclo di vita di tale oggetto e definisce le regole che ne governano le transizioni di stato. Risulta chiaro dunque descrivere questo tipo di diagramma come un automa a stati finiti, pertanto esso sarà costituito da stati, attività e transizioni. Quando un oggetto è in un certo stato infatti, solo determinati eventi causeranno una transizione di stato e non tutti. Viene utilizzato principalmente come completamento della descrizione degli oggetti. Data la sua natura specifica non risulta sempre naturale svilupparlo correttamente e può sembrare non sempre utile al procedere del lavoro, infatti è direttamente dipendente del progetto quali diagrammi siano più o meno efficaci per procedere. 63

×