INGEGNERIA DEL SOFTWARE

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "INGEGNERIA DEL SOFTWARE"

Transcript

1 INGEGNERIA DEL SOFTWARE Indice generale 1) Introduzione 2) Modelli di processo 3) Prject Management 4) Leggere scrivere requisiti 5) Casi d'uso 6) La progettazione del software 7) La progettazione orientata agli oggetti 8) UML e RUP 9) Design Patterns 10) La Progettazione di Architetture Software 11) La qualità del software 12) La manutenzione del software Francesco Russo

2 1. Intoduzione Software: componente di un sistema di elaborazione (di larga diffusione -off the shelf- o commissionato da un singolo committente); prodotto invisibile, intangibile, facilmente duplicabile ma costosissimo; macchina astratta (ha un architettura fatta di componenti e connettori); un servizio (ha un interfaccia e si basa su una infrastruttura). Categorie di sw: Middleware, Open source, Web Services, Software mobile (es. applet), Data mining (es. motori di ricerca), Agenti, Social software (supporta la collaborazione di comunità di utenti), Garanzie sul software: verifica (garantisce l aderenza ad una specifica), validazione (garantisce l accettazione da parte del cliente), certificazione (garantisce l aderenza a specifiche definite dalla legge). NB: il sw commerciale di solito viene venduto senza garanzie ( as is ). 1.1 Ingegneria del software L IdS (Software Engineering) è una disciplina metodologica, cioè studia i metodi di produzione, le teorie alla base dei metodi, e gli strumenti efficaci di sviluppo e misura della qualità di sistemi software complessi. È tuttavia anche una disciplina empirica, cioè basata sull esperienza e sulla storia dei progetti passati. I problemi principali che affronta l IdS riguardano: metodi di analisi e progettazione dei prodotti sw; studio del processo di sviluppo del sw; sviluppo degli strumenti di produzione del sw; aspetti economici dei prodotti e dei processi; standardizzazione di processi e tecnologie. IdS è influenzata da fattori di complessità: aspetti psicologici e organizzativi, scarsa formazione specifica sulla produzione sw, innovazione tecnologica rapidissima, competizione internazionale. Possono esserci diverse cause che portano al fallimento dell'ids: project management inadeguato, requisiti sbagliati, progettazione mediocre, parti interessate con interessi e punti di vista diversi, oppure molti progetti partono assumendosi rischi alti e poco analizzati (66% percentuale fallimenti). Stakeholder: soggetti "portatori di interessi" nei confronti di un'iniziativa economica (progettisti professionisti, management, personale tecnico, decisori, utenti, finanziatori). Ad ogni stakeholder corrisponde almeno un diverso punto di vista (view). Processi di produzione a più livelli: Ciclo di vita industriale Analisi dei requisiti, progetto, testing Progettazione di un servizio sw Progettazione di un modulo e del relativo test. I costi software spesso dominano i costi di produzione di un sistema (sono spesso maggiori dei costi dell hardware sottostante). È più costoso mantenere il software che svilupparlo (manutenzione è circa il 67% dei costi di ciclo); l IdS si preoccupa di produrre software con costi accettabili. Manutenzione a causa del cambiamento; tipi principali di manutenzione: perfettiva (65% - migliorare il prodotto, agisce su funzionalità e efficienza), adattiva (18% - rispondere a modifiche ambientali), correttiva (17% - correggere errori trovati dopo la consegna). I prodotti software sono generici (OTS: off the shelf - sistemi prodotti da produttori di pacchetti software e venduti sul mercato a qualsiasi cliente) o commissionati ( customizzati - sistemi commissionati da un cliente specifico e sviluppati apposta da un qualche fornitore). Attributi dei prodotti software: esterni (visibili all utente - costo e tipo di licenza, prestazioni, garanzia), interni (visibili ai progettisti dimensione, sforzo di produzione (effort), durata della produzione, mantenibilità, modularità). Tra gli attributi troviamo: correttezza (se fa la cosa giusta), manutenibilità, affidabilità (se si rompe, il sw non dovrebbe causare danni), efficienza (il sw non dovrebbe sprecare le risorse di sistema), usabilità (il sw dovrebbe avere interfaccia e documentazione appropriate). L importanza relativa degli attributi di prodotto dipende dal prodotto e dall ambiente in cui verrà usato (es. nei sistemi real time con requisiti di sicurezza, gli attributi chiave sono l affidabilità e l efficienza); se un attributo dev essere particolarmente curato e spinto, i costi di sviluppo tenderanno a crescere esponenzialmente. 1.2 Il processo software Processo software è l'insieme strutturato di ruoli (progettista, sviluppatore, tester, manutentore, ecc.), attività e documenti (codice sorgente, codice eseguibile, specifica, commenti, risultati di test, ecc.) necessari per creare un sistema software. Le attività differiscono in funzione dell organizzazione che sviluppa e del sw da produrre, ma di solito includono: specifica, progetto e sviluppo, verifica e validazione, evoluzione. Per poterle gestire vanno esplicitamente modellate. Attributi di processo: comprensibilità (processo è definito e comprensibile), visibilità (processo progredisce in modo visibile), sostenibilità (processo è sostenuto da strumenti CASE Computer-Aided Software

3 Engineering o ingegneria del software assistita dall'elaboratore), accettabilità (persone implicate nel processo manifestano il loro consenso), affidabilità (errori di processo scoperti prima che diventino errori di prodotto), robustezza (processo può continuare anche in presenza di errori), mantenibilità (processo può evolvere per adattarsi ai cambiamenti nell organizzazione che lo usa), rapidità (processo influenza la velocità di produzione del prodotto). Per far fronte alle problematiche che possono sorgere durante o dopo lo sviluppo del sw, vengono usati principi, tecniche, metodi e strumenti. Principi: anticipazione del cambiamento (considerare i probabili cambiamenti futuri come parte della progettazione), rigore e formalizzazione (applicazione di metodi e tecniche ben definiti, assicurando l affidabilità del prodotto, permettendo il controllo dei costi, aumentando la fiducia dell utente), separazione dei problemi (nonostante molte decisioni di progetto siano correlate e interdipendenti, conviene concentrarsi sui diversi aspetti del problema separatamente), modularità (scomposizione dei problemi), astrazione (identificare gli aspetti importanti di un fenomeno, trascurandone i dettagli meno significativi), generalità (favorisce la riusabilità), incrementalità (procedere passo passo). 1.3 Standard del software Per migliorare qualità di prodotti sw e dei loro processi di produzione. Standard IEEE (principalmente di metodo), Standard OMG (per UML e CORBA), Standard W3C (per tecnologie Web), Standard OASIS (per Business Process). MLOC: mega lines of code SLOC: Source lines of code Fig. Il Body of Knowledge (SWEBOK - IEEE)

4 2. Modelli di processo per lo sviluppo del software Il processo edit compile test: molto veloce, feedback rapido, disponibilità di molti strumenti, specializzato per la codifica, non incoraggia la documentazione, il testing ha bisogno di un processo specifico, non scala in-the-large in-the-many, ingestibile durante la manutenzione. Il processo del debugging: locate errors design error repair repair error re-test program. Il processo di testing: unit t. module t. sub-system t. system t. acceptance t. Unit testing: controllo di componenti individuali. Module testing: controllo di collezioni di componenti correlati. Sub-system testing: controllo di moduli integrati. System testing: controllo dell intero sistema (controllo di proprietà emergenti ). Acceptance testing: testing con dati del cliente per controllare che il comportamento sia accettabile. Verifica e Validazione del sw: la prima dimostra che un sistema è conforme alla specifica, la seconda assicura che un sistema soddisfi i bisogni del committente. Entrambe implicano controlli e processi di revisione e testing di sistema (questo ultimo si basa sull esecuzione su un insieme di casi di test derivati dalla specifica dei dati reali che verranno elaborati durante l attività del sistema stesso). Programming in the small/large/many: small: un programmatore, un modulo = edit-compile-test; large: costruire software decomposto in più moduli, su più versioni e più configurazioni; many: costruire grandi sistemi sw richiede cooperazione e coordinamento di più programmatori, nell ambito di un ciclo di vita. Segmentare il ciclo di vita: suddividere il ciclo di vita in quattro fasi: specifica progetto costruzione manutenzione Specifica: stesura requisiti e descrizione degli scenari d'usi. Progetto: determina un'architettura software capace di soddisfare i requisiti specificati. Costruzione (o codifica): include il testing e termina col deployment (consegna al cliente, con relativa installazione e messa in funzione, di una applicazione o di un sistema software del sistema). Manutenzione: perfettiva, correttiva, adattiva. Fig: Prosecco evolutivo Il software è flessibile e può cambiare, evolversi per adattarsi a nuovi requisiti. Modelli di processo (sw): rappresentazione di una famiglia di processi, presenta la descrizione di istanze di processi sw viste da prospettive particolari. A)a cascata: specifica e sviluppo sono separati e distinti. Molto dettagliato e rigido, orientato alla documentazione e agli standard, adatto per organizzazioni gerarchizzate, rischioso. system requirements analysis ## fase 1 software requirements analysis ## preliminary design ## fase 2 detailed design ## coding & unit testing ## fase 3 component integration & testing ## fase 4 integration testing ## ## fase 5 system testing maintain 1. Analisi dei requisiti: utenti e sviluppatori. Successo se: il sw soddisfa i requisiti, i requisiti soddisfano i bisogni percepiti dall'utente, i bisogni percepiti dall'utente riflettono i bisogni reali. Prodotto di questa fase: documento su cosa il sistema deve fare. 2. Progetto: progettisti sw usano i requisiti per specificare e determinare l'architettura del sistema. Diversi approcci e metodologie (strumenti, supporti linguistici). Prodotto di questa fase: documento

5 di progetto del sistema che identifica moduli e le loro interfacce. 3. Codifica: Prodotto di questa fase: moduli implementati e testati; implementati secondo le loro specifiche, intervengono i linguaggi di programmazione, moduli testati rispetto la propria specifica. 4. Integrazione: moduli sono integrati fra loro, testing delle interazioni fra moduli. Prodotto di questa fase: sistema completamente implementato e testato nelle sue componenti. 5. Test del sistema: il sistema è testato nella sua globalità. Prodotto di questa fase: sistema completamente testato e pronto per essere deployed. V MODEL (sviluppo VS verifica) Modelli orientati alle qualità: i cicli di vita orientati alle qualità si basano su modelli almeno idealmente quantitativi (si misurano i fattori di processo). 1. Cleanroom: teoria basata sulla squadra, orientata al processo di sviluppo e certificazione di alta affidabilità dei sistemi software sotto il controllo di qualità. Un obiettivo principale è lo sviluppo di software che espone zero fallimenti in uso. Combina matematicamente metodi basati sulla specifica del software, la progettazione, la verifica e la correttezza con la statistica, l'utilizzo basati su prove di certificare l'idoneità del software per l'uso. 2. ISO 9000: identifica una serie di norme e linee guida sviluppate dall ISO (International Organization for Standardization), che propongono un sistema di gestione per la qualità, pensato per gestire i processi aziendali affinché siano indirizzati al miglioramento della efficacia e dell'efficienza della organizzazione oltre che alla soddisfazione del cliente. Si suddivide in: ISO 9000 che descrive le terminologia e i principi essenziali dei sistemi di gestione qualità e della loro organizzazione; ISO 9001 (per le fabbriche del sw) per la definizione dei requisiti dei sistemi qualità; ISO 9002 e 9003, la cui certificazione non è riconosciuta in quanto sostituite definitivamente dalla ISO 9001:2000 (prevede un approccio globale e completo di certificazione per cui non è possibile escludere alcuni settori o processi aziendali, se presenti nell'organizzazione o necessari a soddisfare i "clienti"). ISO 9004 è una linea guida per il miglioramento delle prestazioni delle organizzazioni. 3. Capability Maturity Model (CMM): sviluppato dal 1987 al 1997, è un modello che indica ventidue aree di processi aziendali (Process area) strutturate su cinque livelli, ognuna con i propri obiettivi generici (Generic Goal) e specifici (Specific Goal). Gli obiettivi generici e specifici sono implementati da una sequenza temporale di attività generiche (Generic practice) e specifiche (specific practice), che hanno determinate tipologie di output (tipical work product). Livello Caratteristiche Principali problemi Ottimizzante (Quantitativo) Processo misurato Gestito Definito Ripetibile Iniziale (Qualitativo) Processo definito e istituzionalizzato (Qualitativo) Processo definito e istituzionalizzato (Intuitivo) Processo dipendente dagli individui Ad hoc/ Caotico; No stima dei costi, pianificazione, o gestione Identificare identificatori di processo Raccolta automatica di dati di processo per analizzarlo e modificarlo Misurazione del processo; Analisi del processo; Piani di qualità quantitativi Creare un Gruppo di Processo; Identificare un architettura di processo; Introdurre metodi e strumenti di Sw Eng Project management; Pianificazione del progetto; Controllo di qualità del software

6 4. Six Sigma: indica una programma di gestione della qualità basato sul controllo della varianza, (indicata con Sigma) che ha lo scopo di portare la qualità di un prodotto o di un servizio ad un determinato livello, particolarmente favorevole per il consumatore. Mira all eliminazione dei difetti e degli sprechi piuttosto che al semplice miglioramento della prestazione media. ESEMPIO: Un impiegato esce di casa alle 8.00 e deve entrare al lavoro alle Attraversando la città impiega mediamente 25 minuti, mentre per il percorso in campagna (più lungo) occorrono in media 28 minuti. Quale percorso gli conviene? La media non è un indicatore significativo. Si deve analizzare l intera distribuzione dei dati nei due casi: il percorso cittadino presenta una forte variabilità dei dati, perché è molto influenzato (e poco prevedibilmente) dal traffico; il percorso di campagna invece richiede un tempo praticamente costante. Visto l alto numero di difetti nel caso del percorso cittadino, quello di campagna è preferibile dal punto di vista dell impiegato. B) a spirale: rientra nei modelli a processo evolutivo iterativi; specifica e sviluppo sono sovrapposti; adatto se requisiti installabili; non lineare; flessibile; valuta il rischio; può supportare diversi modelli generici. Ad ogni spira è associata una fase del processo. Nessuna sequenza fissa di fasi: si decide via via quale fase reiterare (go not go; per decidere se portare avanti il progetto). Il modello si divide in quattro settori: definizione dell obiettivo (ogni fase identifica i propri obiettivi), valutazione e riduzione dei rischi (ogni rischio deve essere affrontato), sviluppo e validazione (il modello di sviluppo può essere generico, ogni fase include sviluppo e validazione), pianificazione (revisione del progetto e pianificazione del suo futuro). I rischi sono valutati continuamente ed esplicitamente. Si basa, sul concetto di rischio, (circostanza avversa che può pregiudicare il processo di sviluppo e la qualità del software). Il modello si concentra sull identificazione e l eliminazione dei problemi ad alto rischio tralasciando quelli banali. La caratteristica principale del modello è quella di essere ciclico, ogni ciclo di spirale si compone di quattro fasi (come i settori), il raggio rappresenta il costo accumulato e la dimensione angolare il progresso nel processo. La prima fase identifica gli obiettivi e le alternative; le alternative si valutano nella seconda fase in cui vengono evidenziate le potenziali aree di rischio. La terza consiste nello sviluppo e nella verifica del prodotto, e nella quarta avviene la revisione dei risultati delle tre fasi precedenti (pianificazione). Rational Unified Process (RUP) (estensione dello Unified Process) modello di processo software iterativo. Una iterazione è un ciclo di sviluppo che porta al rilascio di una parte del prodotto finale; ogni iterazione tocca tutti gli aspetti dello sviluppo sw; ogni rilascio iterativo è una parte pienamente documentata del sistema finale. Questa scomposizione presenta numerosi vantaggi (in particolare rispetto alla valutazione dell'avanzamento del progetto e alla gestione dei fattori di rischio) ma implica un overhead specifico. Fu descritto in termini di un meta modello objectoriented, espresso in UML. Non definisce un singolo, specifico processo, bensì un framework adattabile che può dar luogo a diversi processi in diversi contesti (per esempio in diverse organizzazioni o nel contesto di progetti con diverse caratteristiche). È pensato soprattutto per progetti di grandi dimensioni. Il ciclo di vita di un processo software è suddiviso in cicli di sviluppo, a loro volta composti da fasi (o iterazioni): Inception Phase (fase iniziale/concezione) Elaboration Phase (fase di elaborazione) Construction Phase (fase di costruzione)

7 Transition Phase (fase di transizione) Iterazioni: sequenze di attività con un piano prestabilito e dei criteri di valutazione, che terminano con un rilascio eseguibile. Il RUP definisce una "Project Management Discipline" (disciplina di gestione dei progetti) a cui il project manager può affidarsi per amministrare le iterazioni. L'Inception Phase: considerata come una particolare elaborazione e precisazione del concetto generale di analisi di fattibilità. Lo scopo è quello di delineare il business case, cioè comprendere il tipo di mercato al quale il progetto afferisce e identificare gli elementi importanti affinché esso conduca a un successo commerciale (per un nuovo sistema o per l'aggiornamento di uno esistente). Se il progetto non supera questa milestone, detta "Lifecycle Objective Milestone", esso dovrà essere abbandonato o ridefinito. Prodotti: requisiti chiave per il progetto, valutazione iniziale del rischio (opzionali: prototipo concettuale, modello del dominio). Elaboration Phase: definisce la struttura complessiva del sistema. Comprende l'analisi di dominio e un prima fase di progettazione dell'architettura. Questa fase deve concludersi con il superamento di una milestone detta "Lifecycle Architecture Milestone". Perciò devono essere soddisfatti i seguenti criteri. Deve essere: sviluppato un modello dei casi d'uso completo al 80%; fornita la descrizione dell'architettura del sistema; sviluppata un'"architettura eseguibile" che dimostra il completamento degli use case significativi; eseguita una revisione del business case e dei rischi; completata una pianificazione del progetto complessivo. Se il progetto non passa questa milestone, viene abbandonato o rivisitato. 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: viene portato a termine il grosso degli sviluppi. Viene prodotta la prima release del sistema. La milestone di questa fase si chiama "Initial Operational Capability" e rappresenta la prima disponibilità delle funzionalità del sistema in termini di implementazione. Scopo: sviluppo incrementale di un prodotto sw completo pronto per essere inserito nella comunità degli utenti. Transition Phase: il sistema passa dall'ambiente dello sviluppo a quello del cliente finale. Vengono condotte le attività di training degli utenti e il beta testing del sistema a scopo di verifica e validazione. Si deve in particolare verificare che il prodotto sia conforme alle aspettative descritte nella fase di Inception. Se così non è si procede a ripetere l'intero ciclo; altrimenti, si raggiunge la milestone detta "Product Release" e lo sviluppo termina. Processo Microsoft: si compone di Pianificazione: (Vision Statement - Product Managers) definisce gli obiettivi del nuovo prodotto o delle nuove funzioni ( features ), le priorità delle funzioni da implementare in base ai bisogni degli utenti. Pianificare con buffer time. Documenti: specifica; pianificazione e definizione dei team di progetto di ciascuna feature. Partecipanti: 1 program manager, 3-8 developers, 3-8 testers (1:1 ratio with developers).(documento programmatico, specifica, team management). Sviluppo: lo sviluppo delle funzioni si divide in 3-4 sotto progetti, ciascuno dei quali esegue in autonomia il ciclo completo di sviluppo, integrazione di feature, testing e debugging. I testers vengono accoppiati agli sviluppatori. Il progetto si stabilizza alla fine del sottoprogetto. Gli utenti vengono coinvolti durante lo sviluppo. Stabilizzazione (collaudo interno ed esterno, preparazione delle release). Usa Synch-and-Stab. L'approccio Synch-and-Stabilize consiste nel sincronizzare di continuo gli sviluppi paralleli e stabilizzare e incrementare periodicamente il prodotto (non tutto alla fine). Processo noto anche con i nomi: milestone process, daily build process, nightly build process, zero-defect process. I principi chiave di Synch&Stab (per definire i prodotti e modellare i processi): 1. Dividere i grandi progetti in più iterazioni con buffer time appropriato (20-50%); 2. Usare un vision statement e classificare le specifiche delle funzioni per guidare il progetto; 3. Selezione delle caratteristiche principali e ordinamento di priorità basato su dati d uso; 4. Architettura modulare; 5. Gestione basata su piccoli compiti individuali e risorse di progetto prestabilite. Il principio base seguito da MS è: Eseguire ogni attività in parallelo, con frequenti sincronizzazioni. Prevede: dividere i grandi progetti in più cicli di traguardi interni, con buffer e nessuna manutenzione separata del prodotto; utilizzare come guida un documento programmatico e un documento di specifica delle funzionalità del prodotto; fondare la scelta delle funzionalità e la scala delle priorità sui dati e le attività dell utente; sviluppare un architettura modulare e orizzontale,

8 in cui la struttura del prodotto sia rispecchiata nella struttura del progetto; controllare un progetto impegnando i singoli in compiti di breve portata e bloccando le risorse del progetto. Tra le metodologie agili (particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente) usate da MS c'è Extreme Programming, caratterizzato dalla programmazione a più mani, la verifica continua del programma durante lo sviluppo per mezzo di programmi di test e la frequente reingegnerizzazione del software, di solito in piccoli passi incrementali, senza dover rispettare fasi di sviluppo particolari. XP si basa su cinque linee guida: communication (tutti possono parlare con tutti, persino l'ultimo dei programmatori con il cliente), simplicity (gli analisti mantengano la descrizione formale il più semplice e chiara possibile), feedback (sin dal primo giorno si testa il codice), courage (si dà in uso il sistema il prima possibile e si implementano i cambiamenti richiesti man mano), respect. Planning game: è la pratica che trasforma la classica analisi dei requisiti in un gioco. Si basa sulle user stories, descrizioni in linguaggio naturale di ciò che l utente vuole che il software faccia. Ad ogni user story gli utenti stessi assegnano una priorità, mentre gli sviluppatori un costo. Ovviamente si tratta di una pianificazione informale. Le storie di più alto rischio e priorità sono affrontate per prime, in incrementi time boxed. Il Planning Game si rigioca dopo ciascun incremento Small release: si sviluppa i vari moduli del sistema software in modo incrementale, ad ogni ciclo si fanno piccole release, minimali, ma comunque utili (mai implementare il database ) in modo da ottenere feedback dal cliente presto e spesso. Eseguire il planning game dopo ciascuna iterazione. Whole team: tutto il team partecipa a ciascun aspetto dello sviluppo software in qualche modo. Collettive ownership deriva dalla pratica precedente; la proprietà intellettuale del codice appartiene al gruppo. Mentre i progettisti sviluppano il progetto possono osservare e modificare qualsiasi classe. Coding Standard: usare convenzioni di codifica. A causa del Pair Programming, delle rifattorizzazioni e della proprietà collettiva del codice, occorre avere sistemi per poter addentrarsi velocemente nel codice altrui. Commentare i metodi (priorità al codice che svela il suo scopo, se non puoi spiegare il codice con un commento, riscrivilo). Soustainable Pace: lavorare fino a tarda notte danneggia le prestazioni: lo sviluppatore stanco fa più

9 errori. Se il progetto danneggia la vita privata dei partecipanti, alla lunga paga il progetto stesso. Metaphore: per descrivere una funzionalità del sistema software nel gruppo si usa una metafora. Ad esempio, per descrivere un gruppo di agenti software in azione lo sciame di piccole api volano sui fiori e rientrano all alveare solo una volta terminato il loro compito. Aiuta a far sì che il team usi un sistema comune di nomi di entità, tale che sia immediato trovare, per uno sviluppatore, una certo modulo in base al nome, o sia chiaro dove inserire le nuove funzionalità appena sviluppate. Contiuos Integration: la coppia scrive i test ed il codice di un task ( = parte di una storia utente), esegue un completo test di unità, esegue l integrazione della nuova unità con le altre, esegue tutti i test di unità, passa al task successivo a mente sgombra (una o due volte al giorno). L obiettivo è prevenire l IntegrationHell. Test-Driven Development: si scrive il codice sulla base dei test stessi. In poche parole si scrivono prima i test, poi si sviluppa l applicazione finché non supera positivamente il test. Questo processo è sempre accompagnato da framework xunit. Refactoring del codice senza pietà!: Uno dei motti del XP è se un metodo necessita di un commento, riscrivilo! (codice auto-esplicativo). Semplificare il codice; cercare opportunità di astrazione; rimuovere il codice duplicato. Simple design: No Big Design Up Front (BDUF) Fare la cosa più semplice che possa funzionare. Includere la documentazione. Schede CRC cards (opzionali). Pair programming: si programma in coppia, il driver (controlla tastiera e mouse e scrive l implementazione) scrive il codice mentre il navigatore (osserva l implementazione cercando difetti e partecipa al brainstorming su richiesta) controlla il lavoro del suo compagno in maniera attiva. I ruoli di driver e navigatore vengono scambiati tra i due progettisti periodicamente. È risultato un ottimo approccio, nonostante possa sembrare uno spreco di risorse umane. Idealmente il cliente è sempre disponibile, in ogni fase del processo di sviluppo per chiarire le storie e per prendere rapidamente decisioni critiche. Gli sviluppatori non devono fare ipotesi ne devono attendere le decisioni del cliente. La comunicazione faccia a faccia minimizza la possibilità di ambiguità ed equivoci. Con l'approccio XP si ha che le coppie producono codice di migliore qualità e nella metà del tempo. Rischi Cowboy Coders Ignore Team s Process; Code Lacks Test Coverage; Stories Are Too Complicated; Customer Doesn t Help Test System; Team Produces Few Customer Tests; QA Department Wants Requirements Specification; Team is Asked to Produce Way More Than it Can; System Contains Many Defects; Team Encounters Risky Technical Challenges; Management Wants System Documentation; Tests Not Run Before Integration; Tests Run Too Slowly. Confronto tra i modelli: CMM (Stabilità, Ripetibilità) RUP (Adattabilità, Connettività) XP (Flessibilità, Agilità). Perchè standardizzare CMM (Predicibilità, Efficienza) RUP (Componentistica, Integrazione) XP (Velocità, Semplicità). La qualità come viene fuori CMM (Rimozione difetti, Prevenzione difetti, Progetto per qualità) RUP (API predefinite, Integrazione semplice, Gestione dei rischi) XP (Fare la cosa più semplice che possa funzionare) C) formale: il modello matematico di un sistema viene trasformato in implementazione D)orientato al riuso: assemblato con componenti preesistenti Opensource può essere definito tramite i seguenti punti: Ridistribuzione libera Codice sorgente incluso nella distribuzione Prodotti derivabili con licenza Protezione dell integrità del sorgente dell autore No discriminazione contro persone o gruppi No discriminazione contro campi applicativi Distribuzione della licenza, che si applica a tutti Licenza non specifica di prodotto Licenza che non vincola altri prodotti sw Licenza tecnologicamente neutrale Filosofia Ogni buon prodotto sw inizia da un problema personale; i bravi programmatori sanno cosa scrivere, i migliori sanno cosa riscrivere; quando hai perso interesse in un programma che hai costruito, è tuo dovere passare le consegne ad un successore competente; trattare gli utenti come sviluppatori è la strada migliore per debugging efficace e rapidi miglioramenti del codice; distribuisci presto e spesso e presta ascolto agli utenti; stabilita una base di betatester e co sviluppatori sufficientemente ampia, ogni problema verrà presto individuato e qualcuno troverà la soluzione adeguata. La Open Source Initiative pubblica una lista di licenze approvate (da un OSI board) e conformi alla Open Source Definition. Esistono molte licenze certificate con caratteristiche diverse. Su richiesta, OSI board può approvare nuove licenze se quelle esistenti non soddisfano le esigenze.

10 Il processo OpenSource è pubblico ; le implementazioni sono controllate da un board che revisiona e testa il codice proposto; modifiche moderate; build frequenti; proprietà collettiva; no maintenance.

11 3. Project Management dei Progetti Software Project Management: applicazione di conoscenze, abilità, tecniche e strumenti alle attività di progetto allo scopo di soddisfarne i requisiti. Il Project Manager (PM, o responsabile di progetto) controlla la pianificazione ed il budget di progetto. Durante tutto il ciclo di vita il PM deve controllare costi e risorse di un progetto: inizialmente per verificare la fattibilità del progetto; durante il progetto per controllare che le risorse non vengano sprecate ed i budget vengano rispettati; alla fine per confrontare preventivo e consuntivo. La valutazione dei costi procede in base alla durata (estensione temporale del progetto, dall'inizio alla fine; dipende dalle dipendenze tra le attività di progetto; si misura di solito in mesi) o allo sforzo (somma dei tempi di tutte le attività di progetto; si misura di solito in mesi/persona mp). I progetti informatici di solito vengono sottostimati sia in durata che in sforzo. Costo di un progetto: il costo è una risorsa impiegata o ceduta per raggiungere un obiettivo o per ottenere qualcosa in cambio; si misura in unità monetarie. Il Project Cost Management definisce i processi necessari ad assicurare che il progetto si concluda con successo entro i termini di budget prestabiliti. Tra i processi troviamo: Resource planning (determinare e pianificare le risorse da usare), Cost estimating (stimare costi e risorse necessarie ad un progetto), Cost budgeting (allocare il costo complessivo su compiti individuali per stabilire un riferimento per valutare le prestazioni), Cost control (controllare le modifiche al budget durante il progetto). Un prodotto importante del Project Cost Management è una stima dei costi. Esistono parecchi tipi di stima dei costi, e di corrispondenti tecniche e strumenti per calcolarli. Occorre anche sviluppare un piano di cost management che descriva come il progetto possa gestire variazioni dei costi. Stimare il costo di un progetto (specie quando produce software) è un arte. Ogni organizzazione che esegue progetti deve creare un database dei costi per supportare le stime correnti e future. Tre tecniche principali di stima dei costi: top-down (o analogica): uso del costo reale di un progetto analogo come base della stima del nuovo progetto; sono dapprima valutati i costi complessivi del progetto, poi si procede alla loro suddivisione nelle fasi di produzione; bottom-up: stima dei compiti individuali che compongono il progetto e loro somma per ottenere la stima totale. Approccio basato sulla dimensione del codice: per ciascun componente elementare viene stimata la dimensione in base ad una metrica prescelta. La stima delle dimensioni è calcolata sommando tutte le stime calcolate in precedenza: il costo complessivo è quindi ottenuto applicando opportuni fattori di costo. Per ogni componente sono date tre stime della dimensione: ottimistica, verosimile e pessimistica. Approccio basato sulla stima dello sforzo: per ciascun componente è stimato lo sforzo necessario per ciascuna fase del processo di sviluppo (sforzo in mesi/uomo). Uso di tabella in cui: ogni riga corrisponde ad un componente; ogni colonna ad una fase dello sviluppo; le ultime tre righe contengono i valori per calcolare i costi. parametrica: stima basata sull uso di un modello matematico che usa parametri di progetto. L attività di stima durante un grosso progetto software richiede sforzo notevole ed è un compito complesso, in più molte persone che effettuano stime hanno scarsa esperienza in tale attività: occorre formazione specifica. Di solito si tende a sottostimare. Le revisioni di stima devono basarsi sulle domande giuste, per evitare che le stime siano falsate. Ai dirigenti occorre un numero per fare un offerta, non una vera stima. Poi è compito dei PM mediare con gli sponsor di un progetto per creare stime di costo realistiche. I principali componenti di costo sw sono: costo dell hardware di sviluppo; costo del software di sviluppo; costo delle risorse umane (sforzo); durata complessiva. Per stimare rapidamente alcuni parametri chiave di un progetto, esistono alcune regole euristiche (Boehm) che aiutano a dare una stima immediata se è nota la misura dello sforzo in mesi-persona (mp): Durata media di un progetto = 2.5 * radice cubica di mp; Dimensione ottimale dello staff = radice quadrata di mp; Durata minima di un progetto = 0.75 * radice cubica di mp. La curva di Rayleigh La curva di distribuzione dello sforzo venne suggerita negli anni 50 per lo sviluppo hw, e viene comunemente usata anche per il sw (t = mese, td = mese del picco di sforzo massimo). Osservando la curva (x = mesi, y = mp) si nota che duante la fase dei requisiti e del design lo sforzo aumenta, sino a toccare il suo massimo durante la codifica; dopo di che procede in lenta discesa durante i test e manutenzioni.

12 Strumenti Sw per il Cost Management: fogli elettronici, usati per resource planning, cost estimating, cost budgeting, e cost control; alcune aziende usano applicazioni finanziarie centralizzate per gestire le informazioni sui costi. Gli strumenti per Project Management offrono parecchie funzioni di analisi dei costi. Tecniche di Stima dei Costi Il giudizio di esperti (metodo Delphi): vengono consultati esperti sulle tecniche di stima del software, i quali stimano indipendentemente il costo del progetto e reiterano finché non si trovano in accordo. Stima per analogia: si applica quando sono già stati completati altri progetti con caratteristiche simili. Il costo viene valutato in analogia al progetto già finito. Legge di Parkinson: la previsione di durata e sforzo aumenta fino a coprire il tempo e le persone disponibili; il costo è quindi determinato dalle risorse disponibili piuttosto che dal bisogno oggettivo. Pricing to Win: il costo del software viene stimato in base alla spesa che il cliente è disposto a sostenere per il progetto. Modelli parametrici (o algoritmici): il costo è stimato come una funzione matematica di attributi i cui valori sono determinati dal manager di progetto. La funzione deriva da uno studio di precedenti progetti (regressione). Attributi chiave: quelli che hanno un impatto significativo sul costo. Uso di strumenti di intelligenza artificiale e apprendimento automatica (reti neurali, Case Based Reasoning, Fuzzy logic): il sistema impara a stimare usando un insieme di dati da progetti già finiti (detto training set); la stima non è spiegata, e può essere inaccurata se il training set è piccolo. In molti progetti alcune tecniche possono essere combinate. Se si predicono costi radicalmente differenti allora bisogna cercare più informazioni e le stime vanno ripetute fino a quando non convergono. L accuratezza della stima deve crescere con il progredire del progetto. 3.1 Misurare le dimensioni del progetto La dimensione di un progetto sw è il primo coefficiente di costo in molti modelli; esistono due misure principali per stimare la dimensione del software da produrre: linee di codice sorgente (LOC). LOC può tener conto delle linee vuote o dei commenti (CLOC); in generale si ha: LOC = NCLOC + CLOC, cioè i commenti si contano. KLOC = Migliaia di linee di codice sorgente. Metriche: $ per KLOC, errori o difetti per KLOC, LOC per mese/persona, pagine di documentazione per KLOC, errori per mese-persona, $/pagina di documentazione. Queste metriche dipendono dal linguaggio di programmazione e penalizzano (sottovalutano la produttività) programmi scritti bene e concisi. Potremmo trovare aspetti critici delle stime dimensionali: è difficile stimare la dimensione in LOC di una nuova applicazione; la stima LOC non tiene conto della diversa complessità e potenza delle istruzioni (di uno stesso linguaggio o di più linguaggi); è difficile definire precisamente il criterio di conteggio (istruzioni spezzate su più righe, più istruzioni su una riga..); maggior produttività in LOC potrebbe comportare più codice di cattiva qualità? Il codice non consegnato (es. test) va contato? punti funzione (Function Points [Albrecht]): metrica che misura funzionalità del sistema. Calcolo di FP: Passo1: si descrive l applicazione da realizzare partendo da una descrizione del sistema (specifica) di natura funzionale. Passo2: individuare nella descrizione i seguenti elementi funzionali: External Input (informazioni, dati forniti dall utente, es. nome di file, scelte di menù, campi di input), External Output (informazioni, dati forniti all utente dell applicazione, es. report, messaggi d errore), External Inquiry (sequenze interattive di richieste risposte), External Interface File (interfacce con altri sistemi informativi esterni), Internal Logical File (file principali logici gestiti nel sistema). Passo3: occorre classificare i singoli elementi funzionali per complessità di progetto, usando la tabella di pesi raffigurata a fianco. Passo4: censire gli elementi di ciascun tipo, moltiplicare per il lor peso e sommare: UFC= Sum [i=1_5] ( Sum [j=1_3] ( elemento i,j * peso i,j)). Dove, i=tipo elemento, j=complessità (semplice, media o complessa), UFC=Unajdjusted Function Count. Passo5: Moltiplicare UFC per il fattore di complessità tecnica dell applicazione (TFC). Calcolo di TFC: TFC = * S [i =1-14] Fi. Ciascun Fi assume un valore tra 0 (irrilevante) e 5 (massimo). PassoFinale: Nota: il valore complessivo di TFC varia nell intervallo da 0.65 (applicazione facile) a 1.35 (applicazione difficile). Alla fine la formula risulta: FP = UFC * TFC (function point). Il conteggio degli FP si basa su giudizi soggettivi, quindi persone diverse possono raggiungere risultati diversi. Quando si introduce la FPA in una organizzazione, è necessaria una fase di calibrazione, usando i progetti sviluppati in passato come base del sistema di conteggio. Problemi: i logical files sono difficili da definire; riconoscimento esplicito dei dati da elaborare; pesi

13 insufficienti alla complessità interna; validità dei pesi e consistenza della loro applicazione; la produttività in termini di FP sembra funzione della dimensione del progetto; gli FP sono stati estensivamente usati con sistemi informativi (minore esperienza con sistemi client-server o embedded). Entrambe queste misure hanno bisogno di dati storici per poter essere calibrate all organizzazione che le usa. Se occorre, è possibile usare la tecnica del backfiring, che permette di convertire LOC in FP e viceversa; si basa sulla nozione di livello di astrazione dei linguaggi di programmazione. Misure derivate dai FP: Produttività: Ore per FP: misura il numero di ore necessarie in media per sviluppare un FP; calcolo: Ore totali di progetto / # FP consegnati; Produttività generale: è la produttività complessiva di gruppo di produzione IT; calcolo: FP totali / Sforzo totale del gruppo; Funzionalità consegnata & Funzionalità di sviluppo: funzionalità consegnate all utente finale in relazione al tasso di produttività raggiunto per tali funzionalità; Calcolo: Costo totale / # FP consegnati, Sforzo totale / # FP sviluppati internamente. 3.2 Altre misure e stime Misure di qualità: Dimensione dei requisiti funzionali: misura il numero totale di funzioni richieste in FP; Completezza: misura la funzionalità consegnata rispetto a quella richiesta inizialmente; calcolo: #FP consegnati / #FP richiesti; Produttività di consegna: produttività necessaria alla consegna entro un certo periodo di durata del progetto; calcolo: # FP totali / Durata dello sforzo; Efficienza nella rimozione di difetti: # difetti trovati prima della consegna / # difetti totali; Densità dei difetti: numero di difetti identificati in una o più fasi del ciclo di vita in rapporto alla dimensione totale dell applicazione; calcolo: # difetti / # FP totali; Copertura dei casi di test: numero dei casi di test necessari ad un controllo accurato del progetto; calcolo: # casi di test totali / # FP totali; Volume della documentazione: misura o stima delle pagine prodotte o previste come effetto dello sviluppo; calcolo: # pagine / # FP totali. Misure finanziare: Costo per function point: il costo medio della realizzazione di ciascun FP; calc: Costo totale / # FP totali; Costo di una riparazione: costo di riparazione di applicazioni consegnate ed operative; è una metrica di monitoraggio di nuove applicazioni; calcolo: (Ore totali di riparazione * Costo_orario) / # FP rilasciate: Misure di manutenzione: Mantenibilità: misura del costo necessario per mantenere un applicazione; calcolo: Costo di manutenzione / # FP totali dell applicazione: Affidabilità: numero dei fallimenti in rapporto alla dimensione dell applicazione; calcolo: # fallimenti / # FP totali dell applicazione: Impegno di manutenzione: dimensione dell applicazione rapportata al numero di risorse a tempo pieno necessarie per il suo supporto; calcolo: # FP totali dell applicazione / # persone a tempo pieno impiegate per la manutenzione; Tasso di accrescimento: crescita delle funzionalità di un applicazione in un certo periodo; calcolo: # FP correnti / # FP originali; Dimensione del patrimonio: misura del patrimonio di FP di un organizzazione; si usa per scopi di budget in accordi di outsourcing; Valore di Backfire: numero di linee di codice moltiplicate per un fattore di complessità linguistica per derivare il numero totale di FP; Tasso di stabilità: si usa per monitorare quanto effettivamente un applicazione ha soddisfatto i suoi utenti (in base al numero di modifiche richieste nei primi 2-3 mesi di produzione oppure operatività); calcolo: # modifiche / # FP totali dell applicazione. Stima Basata Su Modelli di Costo I modelli di costo permettono una stima rapida dello sforzo; questa stima è poi raffinata, più avanti nel ciclo di vita, mediante dei fattori detti cost driver. Il calcolo si basa sull equazione dello sforzo: E = A + B*(S^C), dove E è lo sforzo (in mesi-persona), A, B, C sono parametri dipendenti dal progetto e dall organizzazione che lo esegue, S è la dimensione del prodotto stimata in KLOC o FP. Problemi dei costi del software: mentre i costi hardware diminuiscono, i costi del software continuano ad aumentare, almeno in percentuale dei costi totali dei sistemi informativi. I problemi di stima dei costi sw sono causati da: incapacità di dimensionare accuratamente un progetto; incapacità di definire nel suo

14 complesso il processo e l ambiente operativo di un progetto; valutazione inadeguata del personale, in quantità e qualità; mancanza di requisiti di qualità per la stima di attività specifiche nell ambito del progetto. Sono esempi di modelli dei costi del software, modelli commerciali: COCOMO; COSTXPERT; SLIM; SEER; Costar, REVIC, etc. 3.3 COCOMO Il Constructive Cost Model (COCOMO) è uno dei modelli più diffusi per fare stime nei progetti software, basato su regressione (cioè su un archivio storico) che considera vari parametri del prodotto e dell organizzazione che lo produce, pesati mediante una griglia di valutazione. Il principale calcolo di COCOMO si basa sull Equazione dello Sforzo, che stima il numero di mesi-persona necessari per un progetto. La maggior parte delle altre grandezze da stimare (la durata del progetto, la dimensione dello staff da impiegare, ecc.) vengono poi derivate da questa equazione. Es.: # mp * costo_lavoro = Costo_Stimato. Boehm costruì la prima versione del modello di costo CoCoMo 1 nel 1981; è una collezione di tre modelli: Basic (applicato all inizio del ciclo di vita del progetto), Intermediate (applicato dopo la specifica dei requisiti), Advance (applicato al termine della fase di design). I tre modelli hanno forma equazionale Effort = a*(s^b)*eaf, dove: Effort è lo sforzo in mesi-persona; EAF il coefficiente di assestamento; S la dimensione stimata del codice sorgente da consegnare, misurata in migliaia di linee di codice sorgente (KSLOC); a e b sono coefficienti che dipendono dal tipo di progetto. I vari valori e coefficienti variano a seconda del tipo di progetto: Organic mode (progetto semplice, sviluppato in un piccolo team), Semidetached mode (progetto intermedio), Embedded (requisiti molto vincolanti e in campi non ben conosciuti). Il modelloodello intermedio, più usato con COCOMO 1, aggiunge al risultato del modello base (in cui ci sono solo coefficinti fissi) un fattore di aggiustamento che lo può accrescere o decrescere, identificando un insieme di attributi che influenzano il costo (detti cost driver), ottenendo risultati con una buona precisione. Tipi di cost drivers: del personale (capacità ed esperienza degli analisti e dei programmatori, conoscenza del linguaggio di programmazione utilizzato), del prodotto (affidabilità richiesta, dimensione del DB, complessità del prodotto), del computer (tempo di esecuzione del programma, limitazioni di memoria), del progetto (tools software disponibili, tempo di sviluppo del programma). CoCoMo 2 rinnova CoCoMo 1 supportando: sw orientati agli oggetti, sw creati con ciclo di vita a spirale o con modelli di processo evolutivi, sw per e-commerce. Il metodo COCOMO2 come unità di misura della dimensione del software (Size) può usare le KSLOC oppure i FP. Contiene 3 diversi modelli: Early Design Model, per stime preliminari, basato su UFP; Post-Architecture Model, da usarsi dopo che è stata delineata l'architettura (ha nuovi cost drivers e nuove equazioni); Application Composition Model, per GUI. Vediamo COCOMO 2 (2000) nella versione PostArchitecture : il metodo presuppone una stima preliminare della dimensione del codice da sviluppare; il risultato dell'applicazione del metodo è una stima dello sforzo di sviluppo che una specifica organizzazione dovrà "spendere" per costruire un codice di tale dimensione; buona precisione del metodo (circa ± 25%). L'applicazione del metodo si basa su: analisi dei componenti da stimare; costituzione e analisi di uno storico; stima del Size (SLOC o FP); stima dei parametri (fattori di scala + cost drivers); calcolo dello sforzo. Equazione dello sforzo = A * (Size^ES) * EM, dove A fattore di calibrazione da storico, ES somma di fattori di scala relativi a prodotto, processo e organizzazione, EM produttoria di cost drivers relativi a prodotto, processo e organizzazione, Storico insieme di dati di processo su componenti costruite in passato, Size dimensione dei componenti da produrre. Occorre calibrare quattro costanti chiamate A B C D che si ricavano da un archivio storico di progetti. Calcolo di A (calibrazione): A rappresenta la precisione storica di stima. Il calcolo del coefficiente A è molto sensibile alla scelta dei progetti da inserire nello storico. A(originale) = 2.94, ottenuto dalla calibrazione COCOMO fatta dal gruppo di Bohem su un centinaio di progetti industriali. Calcolo di ES: ES rappresenta una scala (de)amplificatrice di sforzo direttamente basata su SIZE; è una somma, ES = 0,91 + (PREC + FLEX + RESL + TEAM + PMAT)/100. ES è calcolato per ogni singolo componente sulla base dello storico (diviso in 8 profili); spesso ES>1 (se il progetto permette economie di scala allora ES<1). Calcolo di EM: EM rappresenta il peso combinato di fattori (cost driver) di prodotto, di processo e organizzativi; i cost driver si moltiplicano.

15 4. Scrivere e leggere requisiti Per stesura dei requisiti si intende stabilire cosa richiede il cliente ad un prodotto software (non stabilire come il prodotto verrà costruito). Ingegneria dei requisiti è il processo di definizione dei: servizi che un cliente richiede ad un sistema vincoli di sviluppo di un sistema scenari d uso del sistema vincoli operativi di un sistema Comprende: elicitazione, specifica, gestione, analisi e verifica dei requisiti. Tecniche di elicitazione: interviste e questionari, riunioni (workshop) dei requisiti, brainstorming, storyboards, casi d uso, giochi di ruolo, prototipazione. Attività di elicitazione: identificare gli attori, i casi d uso e relazioni tra essi, gli scenari, requisiti non funzionali e gli oggetti partecipanti; raffinare i casi d uso. Un requisito può essere una descrizione astratta e vaga di un servizio o vincolo di sistema, oppure una specifica dettagliata di una funzionalità del sistema. I requisiti hanno infatti una doppia funzione: base per un offerta di contratto (devono essere aperti a varie interpretazioni); base per un contratto (devono essere dettagliati e non soggetti ad interpretazioni arbitrarie). Quindi possono essere definiti come proprietà di un sistema o prodotto desiderate dai suoi acquirenti o come descrizione in linguaggio naturale dei servizi e dei vincoli operativi di un sistema (si scrive per i clienti). Lo standard IEEE definisce l'uso del Software Requirement Specification document (SRS) il cui punto di partenza è costituito dalla definizione di sette attributi di qualità (unambigous, correct, complete, verifiable, consistent, modifiable, traceable, ranked - for importance and/or stability). Il documento fornisce feedback all utente; decompone un problema in sottoproblemi in modo ordinato e orientato a componenti indipendenti; serve come input per la fase di progettazione, verifica e validazione. Un aspetto importante da evitare è l'inconsistenza dei requisiti: difficile anticipare l'effetto di un nuovo servizio software sull'organizzazione che lo sviluppa; utenti diversi hanno priorità e requisiti diversi; gli utenti finali hanno aspettative diverse da quelle di chi finanzia lo sviluppo; per chiarire i requisiti è spesso utile l uso di prototipi. Classificazione dei requisiti (alcuni requisiti possono essere sia funzionali che non, es. di sicurezza): funzionali: descrivono le interazioni tra il sistema ed il suo ambiente, indipendentemente dall implementazione (es. questa procedura stampa un documento); non funzionali: proprietà del sistema visibili all utente e non direttamente correlate al suo comportamento funzionale (vincoli sui servizi offerti come affidabilità, robustezza, usabilità, vincoli temporali, memoria, ecc., es. questo documento deve esser stampato su stampante a colori). Possono essere più critici di quelli funzionali, se non rispettati possono rendere il sistema inutile. Questa famiglia può esser ulteriormente classificata in: requisiti di prodotto (specificano il comportamento del prodotto al momento del rilascio come velocità di esecuzione, attendibilità, ecc.); di processo (possono essere demandati, delegati, ad un particolare sistema CASE o metodo di sviluppo); organizzativi (o aziendali, dipendono dalle politiche e le procedure adottate dall'organizzazione, cioè standard di processi usati, requisiti di implementazione, ecc.); esterni (sorgono da fattori esterni al sistema e al suo ambiente di sviluppo, cioè requisiti di interoperabilità, legislativi, ecc.); vincoli ( Pseudo requisiti ): imposti dal cliente o dall ambiente operativo in cui funzionerà il sistema (es: il linguaggio di programmazione dev essere Java). Secondo l'ingegneria dei requisiti vengono fatte ulteriori distinzioni: requisiti utente: funzionali e non funzionali, definiti in linguaggio naturale e diagrammi informali comprensibili dagli utenti (il documento è scritto per gli utilizzatori); descrivono i servizi offerti; requisiti di sistema: documento strutturato che descrive dettagliatamente il comportamento del sistema, visto come entità unitaria (contratto tra cliente); possono essere requisiti emergenti, cioè non direttamente derivabili o conseguenti da alcun sottoinsieme dei requisiti; requisiti architetturali: documento contenente una descrizione dettagliata dell architettura sw che servirà come base per la progettazione e implementazione (scritto per gli sviluppatori). La scrittura dei requisiti può avvenire con: linguaggio naturale, va in contro a problemi di tipo: scrittori e lettori della specifica dovrebbero usare le stesse parole per lo stesso concetto; una specifica è sempre soggetta a più interpretazioni; i requisiti non vengono partizionati da strutture linguistiche specifiche. Più precisamente: mancanza di chiarezza (più il documento è preciso, meno sarà leggibile), confusione (requisiti funzionali e non vengono facilmente mescolati), amalgamazione (potranno essere espressi in singole fasi più requisiti insieme); linguaggio naturale strutturato, forma ristretta del precedente, rimuove parte dei problemi di ambiguità e impone uniformità al documento di specifica; spesso si basa su una serie di documenti schematici (form);

16 notazioni visuali (es. UML) e specifiche formali (es. Z). Il processo di stesura dei requisiti è l'insieme di fasi che portano alla scrittura del documento dei requisiti che contiene la definizione ufficiale di cosa viene richiesto agli sviluppatori, includendo sia la definizione (descrizione in linguaggio naturale dei servizi e dei vincoli operativi di un sistema, scritto per i clienti) che la specifica (documento strutturato che dettaglia i servizi attesi dal sistema, scritto per i contraenti e gli sviluppatori, come contratto tra cliente e contraente) dei requisiti. Non è un documento di progettazione, dice cosa il sistema deve fare, non come. Deve: specificare il comportamento del sistema (dal punto di vista esterno) e i vincoli realizzativi; essere facilmente modificabile e servire da riferimento per la manutenzione; predire possibili cambiamenti al sistema e definire le risposte del sistema ad eventi inaspettati Il documento dei requisiti è strutturato in sei moduli: introduzione (definizione dei requisiti - descrive perché si costruisce il sistema e come risponde ai bisogni dell organizzazione), requisiti funzionali (descrive in dettaglio i servizi da fornire), requisiti non-funzionali (definisce i vincoli sul sistema e sul suo processo di sviluppo), evoluzione del sistema (definisce le assunzioni critiche su cui si basa il sistema ed anticipare i possibili cambiamenti), glossario (definisce i termini tecnici usati, deve essere il più completo e sintetico possibile), indici generale e analitico. Dev essere organizzato in modo che possa essere modificato senza bisogno di riscriverlo completamente, dev essere modulare e i riferimenti all esterno del documento devono essere pochi, possibilmente nessuno (il documento dev essere autocontenuto). La prima pagina del documento dei requisiti contiene informazioni generali sul prodotto o progetto (nome, data, autori, vers.), esplica le responsabilità di ciascun autore e definisce i cambiamenti dall ultima versione. Non tutti i requisiti hanno la stessa importanza, perciò vengono divisi in tre classi di priorità: obbligatori, desiderabili, opzionali. I requisiti correlati devono essere collegati e magari collegati anche alla fonte: questa operazione prende il nome di tracciabilità dei requisiti (la tracciabilità è una proprietà della specifica dei requisiti che permette di trovare facilmente i requisiti correlati). Sono disponibili tecniche per questa operazione che costruire una lista dei riferimenti incrociati ai requisiti usando identificatori unici assegnati precedentemente; possono essere usati link ipertestuali (es. HTML) per realizzare meccanismi di navigazione della tracciabilità. Verificabilità dei requisiti: i requisiti vanno scritti in modo che possano essere oggettivamente verificati nel prodotto finale; occorre quantificare il tasso degli errori. Validazione dei requisiti: è la dimostrazione che i requisiti definiscono il sistema davvero voluto dal cliente. Il costo di un errore nei requisiti è molto alto, quindi la validazione è importante (la correzione di un errore nei requisiti dopo la consegna può costare oltre 100 volte il costo di correzione di un errore implementativo). La tecnica più importante di validazione dei requisiti è la prototipazione Il controllo dei requisiti si basa sulle seguenti proprietà: validità (dimostrazione che i requisiti definiscono il sistema davvero voluto dal cliente, es. di tecnica è la prototipazione), consistenza (se ci sono conflitti tra i requisiti), completezza (se sono incluse tutte le funzioni richieste dal cliente), realisticità (se i requisiti sono soddisfacibili dato il budget disponibile e la tecnologia corrente). Revisioni dei requisiti: dovrebbero essere fatte regolarmente durante il periodo di definizione dei requisiti. Servono ad affrontare problemi o errori di specifica nella fase iniziale del processo; possono essere formali (strutturate) o informali. Alle revisioni partecipano sia persone del cliente, sia del contraente. Anche per questa fase sono disponibili controlli che mirano a verificare le seguenti proprietà: verificabilità (se il requisito è realisticamente controllabile), comprensibilità (se il requisito si capisce correttamente), tracciabilità (se l'origine del requisito è definita correttamente), adattabilità (se il requisito può essere modificato senza influenzare pesantemente gli altri requisiti). Evoluzione dei requisiti, perché si capiscono meglio i bisogni dell utente o gli obiettivi dell organizzazione cambiano; è importante perciò anticipare e pianificare il cambiamento dei requisiti mentre il sistema viene sviluppato ed usato. Possiamo quindi fare un altra classificazione: requisiti duraturi (o stabili, tipici del dominio dell'applicazione o dell'organizzazione che la userà, es. regole di privacy negli ospedali) e effimeri (o volatili, che cambiano durante lo sviluppo o dopo che l'applicazione è divenuta operativa; dipendono dall'ambiente, es. gestione di certe malattie negli ospedali).

17 5. Casi d'uso Un Caso d Uso è una vista sul sistema che mostra il suo comportamento come apparirà agli utenti esterni. Partiziona le funzionalità in transazioni (casi d uso) significative per gli utenti (attori). Rappresenta un requisito funzionale di un sistema che si costruisce dialogando con l utente (elicitazione) e viene usato per costruire i modelli sia strutturali che operazionali, e inoltre per predisporre casi di test. Il Caso d Uso è una descrizione del comportamento di un sistema dal punto di vista di un utente. I casi d uso possono essere descritti sotto forma di scenario (un dialogo, o sequenza di azioni che rappresenta l interazione di entità esterne al sistema -attori- con il sistema stesso o sue componenti) tra gli utilizzatori e il sistema. Un caso d uso è un insieme di scenari legati da un obiettivo comune. L attenzione si focalizza quindi sull interazione, non sulle attività interne al sistema. Si distinguono due tipi di scenari: base: è di solito quello che prevede il successo del caso d uso, ed uno svolgimento lineare; alternativi: possono essere di successo o fallimento, con complicazioni varie; non è necessario (e sarebbe molto costoso) analizzare in dettaglio tutti i possibili scenari di un caso d uso; è invece necessario individuare le singole possibili varianti che possono portare al fallimento del caso d uso, o che comportano trattamenti particolari. Un caso d'uso specifica cosa ci si aspetta da un sistema nascondendone il suo comportamento; è una sequenza di azioni (con varianti) che producono un risultato osservabile da un attore. Si usa per descrivere requisiti d utente (analisi iniziale) e convalidare l architettura /verificare il sistema. Le sequenze di azioni, o flussi di eventi, possono essere: testuali (informale, formale, semi formale) in cui il flusso è diviso in flusso principale (di base o primario) e uno o più flussi eccezione (alternativi); oppure diagrammatici (diagrammi di interazione). Tale sequenza descrive solo gli eventi relativi al caso d uso, e non quel che avviene in altri casi d uso; evita l uso di termini vaghi (come "per esempio", "ecc." o "informazione"). Il flusso degli eventi dovrebbe descrivere: come e quando il caso d uso inizia e finisce, quando interagisce con gli attori; quali informazioni sono scambiate tra un attore e il caso d uso, tralasciando i dettagli dell interfaccia utente. Attori: descrivono un ruolo che una persona o un dispositivo hardware o un sistema gioca rispetto al sistema; eseguono casi d uso (prima si cercano gli attori, poi i loro casi d uso); possono non essere una persona (ad es. un altro sistema o contenitore di informazioni); possono essere specializzati. Sono disponibili istanze di attori che permettono ad un utente di agire come attori diversi, ad esempio come operatore e cliente. Gli attori vengono connessi ai casi d'uso mediante associazioni (relazioni di comunicazione, in cui entrambi possono mandare o ricevere messaggi). Nel definire gli attori si possono adottare due diversi punti di vista che corrispondono a diversi livelli di astrazione: uno indipendente da particolari soluzioni organizzative e tecnologiche (modello dell ambito "business workflow") ed uno legato ad una particolare soluzione organizzativa e tecnologica (modello dei servizi del sistema informatico). Possiamo quindi considerare due tipi di attori: buisness e di servizio. Un caso d uso consiste di: un unico nome; attori partecipanti; condizioni d ingresso (precondizioni, ciò che deve esser vero prima che il caso d'uso possa iniziare); flusso degli eventi; condizioni d uscita (postcondizioni, ciò che sarà vero al termine del caso d'uso). Rappresentano fonti di informazione per i casi d uso le specifiche del sistema, la bibliografia del dominio del sistema, interviste con gli esperti del dominio, la conoscenza personale del dominio e l'osservazione di sistemi già esistenti. Sono documentati da: Una breve descrizione: descrizione generica e sequenziale del flusso di eventi di un caso d uso che consiste nel descrivere la precondizione (stato iniziale del sistema) ed elencare la sequenza di passi; Include le interazioni con gli attori e descrive quali entità vengono scambiate; può contenere punti di estensione ma dev essere chiara, precisa e breve; Flusso dettagliato degli eventi: descrizione dei flussi primari ed alternativi (usati anche per gestire situazioni erronee) degli eventi che seguono lo start-up dello use case. La documentazione dovrebbe essere come un dialogo tra l attore e lo use case perciò tutti i documenti sono scritti in modo comprensibile per il cliente. 5.1 Organizzare i casi d'uso Generalizzazione: Il caso figlio eredita comportamento e significato dal caso genitore; può aggiungere o modificare comportamento del genitore; può essere sostituito in qualsiasi punto appaia il genitore. Inclusione: Si usa per non descrivere più volte lo stesso flusso di eventi, inserendo il comportamento comune in un caso d uso a parte. Evita di copiare parti di descrizioni di casi d'uso. Quindi: fattorizza

18 comportamento comune, spesso nessun attore è associato al caso d uso comune, sono possibili attori diversi per i casi d uso chiamanti. Estensione: Permette di modellare la parte opzionale di un caso d uso e i sottoflussi condizionali; permette di inserire un sottoflusso in un punto specifico, regolato da un interazione con un attore. Punti estensione (nei flussi testuali). Quindi: distingue le varianti, gli attori associati eseguono il caso d uso e tutte le estensioni, l attore è collegato al caso base. Possono essere definite le seguenti proprietà per i casi d'uso: granularità (fine o grande); conseguire un obiettivo preciso; i casi d uso descrivono funzionalità osservabili dall esterno del sistema; spesso catturano funzioni visibili agli utenti; servono come base per il testing. Andiamo ora ad analizzare la stesura dei casi d'uso che procede tramite l'adempimento di cinque punti: identificare gli attori che interagiscono col sistema; organizzare gli attori; considerare l interazione principale; cercare le eccezioni agli scenari principali; organizzare i comportamenti come casi d uso, usando le relazioni di generalizzazione, inclusione ed estensione. ESEMPIO: Gestione conto corrente Il sistema usa uno sportello Bancomat L utente deve poter depositare assegni L utente deve poter ritirare contante L utente deve poter chiedere il saldo L utente deve poter ottenere una ricevuta se lo richiede. La ricevuta riporta il tipo di transazione, la data, il numero di conto, la somma, ed il nuovo saldo Dopo ciascuna transazione viene visualizzato il nuovo saldo SOLUZIONE A) Use case: withdraw Precondition: User has selected withdraw option Main flow: Include (Verify user) Prompt user for amount to withdraw Check available funds of user Check available money of ATM Remove amount from account Exceptional flow If not sufficient funds or money available, prompt user for lower amount B) Use case: deposit Precondition: User has selected deposit option Main flow: Include (Verify user) Prompt user for amount of deposit Open slot Get check Give money (print receipt) Print current balance (print receipt) Print (balance+deposited amount) C) Use case: check balance Precondition: User has selected balance option Main flow: Include (Verify user) Print balance D) Use case: verify user Precondition: none Main flow: User enters ID card User enters PIN number System checks validity of card and number Exceptional flow: If combination is not valid, reject user E) Use case: withdraw with receip Precondition: User has selected withdraw option and print receipt option F) Use case: deposit with receipt Precondition: User has selected deposit option and print receipt option

19 6. La progettazione del software La progettazione si apprende studiando i principali paradigmi evolutisi in relazione al progresso della tecnologia e delle applicazioni. È importante distinguere metodologia dal paradigma. La prima è un insieme di metodi, regole e postulati impiegati da una disciplina, che nasce da un analisi dei principi di conoscenza in un dominio specifico e dallo studio dei metodi di analisi di tale dominio. Il secondo rappresenta un esempio, un modello. Il paradigma oggi dominante è l object-oriented. Mentre l analisi si occupa di definire la soluzione giusta per il problema giusto, la progettazione si occupa di descrivere (anticipare) una soluzione al problema mediante un modello (rappresentazione semplificata della realtà che contiene informazioni ottenute focalizzando l attenzione su alcuni aspetti cruciali e ignorando alcuni dettagli) che si ispiri ad un qualche paradigma. Dopo l analisi, distinguiamo almeno due fasi di progettazione: la progettazione architetturale, che decompone il sistema in moduli e determina le relazioni tra i moduli, e la progettazione dettagliata, specifica delle interfacce dei moduli che descrive funzionalmente i moduli stessi. Diversi meccanismi linguistici vengono presi come elementi atomici (paradigmatici) della progettazione architetturale: procedure, funzioni, coroutine, processi, moduli, oggetti, componenti, agenti. L architettura di un sistema software definisce una visione comune che tutte le parti interessate allo sviluppo devono accettare e condividere. Un es. di tale architettura è la Micro-Kernel Architecture: è un approccio che si basa sulla modularizzazione del kernel (il kernel è piccolo ed esegue solo le funzioni essenziali, il resto sono programmi -moduli- a cui il microkernel accede per assolvere a tutte le altre funzioni) il cui diagramma è diviso in tre parti: User Mode (in cui si distinguono i User Processes e i System Processes), Kernel Mode (Micro Kernel), Hardware. Non esistono metodi universali per descrivere le architetture sw; i più diffusi sono: disegni informali, diagrammi UML (vari), linguaggi architetturali. Cosa NON è un architettura: la maggior parte dei casi d uso e delle classi con operazioni, interfacce e attributi privati (nascosti); i casi di test e le procedure di test (di solito meno del 10% delle classi sono rilevanti per l architettura, l altro 90% non è visibile). I modelli del sw richiedono l'uso più viste; un buon modello ne include almeno quattro: vista Teleologica: descrive scopo e usi del sistema da progettare (eg. Documento di Marketing); vista Funzionale: descrive il comportamento di un sistema in relazione allo scopo (eg. Casi d uso); vista Strutturale: descrive i componenti di un sistema e le loro relazioni (elementi e relazioni): vista Comportamentale: descrive il comportamento di un sistema in relazione ai cambiamenti del suo ambiente (interazione dinamica tra Funzionale e Strutturale). Le prime due viste sono soggettive (descrivono le intenzioni del progettista), le seconde oggettive (descrivono proprietà future del sistema). Esempio in UML: Use Cases Interactions between a User & System Process Description Overview of process goals, participants and collaboration. Interaction Diagrams Behavior of core business elements in process. State Diagrams Life cycle of core system elements in process. Class Diagrams Basic business elements and their relationships. Deployment Diagrams Actual structure of the final system Funzione Comportamento Struttura Fig. Visualizzare il software

20 Livelli di astrazione Strutture dati e algoritmo; Classe (strutture dati e molti algoritmi); Package/Moduli (gruppi di classi correlate, magari interagenti via design pattern); Moduli/Sottosistemi (moduli interagenti contenenti ciascuno molte classi; solo le interfacce pubbliche interagiscono con altri moduli/sottosistemi); Sistemi (sistemi interagenti con altri sistemi hardware, software ed esseri umani). La progettazione architetturale riguarda gli ultimi 2 livelli. Modulo è un componente di un sistema che ha un interfaccia ben definita verso gli altri componenti. Facilita la composizione, il riuso e la riparazione del sistema, e rende flessibile la riconfigurazione. Un modulo software è un contenitore di programmi e strutture dati. I moduli sono unità di incapsulamento quando permettono di separare l interfaccia dall implementazione. L interfaccia del modulo esprime ciò che il modulo offre o richiede; gli elementi dell interfaccia sono visibili agli altri moduli. L implementazione del modulo contiene il codice corrispondente agli elementi dell interfaccia e che realizza la semantica del modulo. I moduli software possono essere compilati separatamente, facilitando così lo sviluppo parallelo, il riuso e le riparazioni. Gli obiettivi di progettazione sono: semplicità (spesso si coniuga con eleganza, il codice è più semplice da capire e correggere, riduce gli errori), affidabilità e robustezza (gestire input inattesi, superare gli errori senza crash, non far danni), efficacia (risolvere i problemi giusti, efficienza, integrazione e compatibilità con altro software). Tra due progetti equivalenti è sempre da preferire quello strutturato in modo più semplice possibile, che magari massimizzi la coesione (le relazioni intraclasse) e minimizzi l'accoppiamento (le relazioni interclasse). La coesione dei moduli misura della coerenza funzionale di un modulo software; ogni modulo dovrebbe avere coesione alta. Un modulo ha coerenza funzionale se fa una cosa sola, e la fa bene. Le classi componenti di grossi moduli dovrebbero essere funzionalmente correlate. Ci sono diversi tipi di coesione, che vanno da un basso livello di coerenza (coincidentale) ad uno alto (funzionale): Coincidentale: molteplici azioni e componenti completamente scorrelati; l oggetto non rappresenta una singola nozione o racchiude codice scorrelato; Logica: serie di azioni o componenti correlate (e.g. libreria di funzioni di IO): il modulo contiene funzioni correlate, se ne sceglie una mediante un parametro di invocazione (ad es. switch); Temporale: serie di azioni o componenti simultanee (e.g. moduli di inizializzazione); il modulo raccoglie comandi che vengono elaborati in un certo breve periodo di tempo (es. tipico è il modulo di inizializzazione); Procedurale: serie di azioni che condividono sequenze di passi; Comunicativa: coesione procedurale sugli stessi dati; Funzionale: una sola azione o funzione. Per decidere il livello di coesione possiamo usare una serie di domande passi: Can the moduls be considered to be doing one problem-related function? yes 1. FUNCTIONAL no What relates the activies within the module? Data Is sequence important? yes 2. SEQUENTIAL no 3. COMMUNICATIONAL Flow of control Is sequence important? yes 4. PROCEDURAL no 5. TEMPORAL Neither Are the activitie in the same general categoty? yes 6. LOGICAL no 7. COINCIDENTAL Se le attività in un modulo hanno diversi livelli di coesione, il modulo ha il grado di livello peggiore. L' accoppiamento dei moduli misura del grado di indipendenza di un insieme di moduli software. I moduli di un sistema dovrebbero riportare un accoppiamento basso (o lasco); questo si ottiene quando ci sono solo poche dipendenze tra i moduli, tutte funzionalmente rilevanti e necessarie. In caso contrario, il software è fatto male perché ad esempio risulta difficile da capire, mantenere, correggere, ecc L accoppiamento tra i moduli può essere ridotto eliminando relazioni non necessarie, riducendo il numero o rilassando le relazioni necessarie. Ci sono diversi tipi di accoppiamento, che vanno da un basso livello di indipendenza funzionale di un insieme di moduli ad uno alto in modo crescente: Assenza di accoppiamento;

21 Dati: un modulo produce una struttura dati per un altro modulo che la consuma; output di un modulo è input di un altro (es.: A passa X a B, dunque X e B sono accoppiati, perché una modifica all interfaccia di X richiede una modifica all interfaccia di B); Stamp Couoling: un modulo fornisce parte di una struttura dati per un altro modulo; Controllo: un modulo passa un elemento di controllo ad un altro modulo; Esterno: dati comuni tra due moduli con accesso strutturato; Comune: i due moduli hanno accesso agli stessi dati globali; Contenuto: un modulo che referenzia il contenuto di un altro modulo. Per ridurre le dipendenze vincolando la topologia delle relazioni fra i moduli, viene definita la gerarchia dei moduli di un sistema sw. La struttura gerarchica dei moduli forma la base di progetto in quanto: decompone il dominio del problema, facilita lo sviluppo parallelo, isola le ramificazioni di modifica e versionamento, permette la prototipazione rapida. Alcune relazioni gerarchiche tra moduli sono: X usa Y (dipendenza funzionale, es. call); X è_composto_da {Y,Z,W} (decomposizione architetturale: solo le foglie sono vero codice); X is_a Y (ereditarietà); X has_a Y (contenimento). Lo standard IEEE Software Design Description specifica la forma del documento dell'architettura di sistema software.

22 7. La progettazione orientata agli oggetti I linguaggi ad oggetti includono un tipo di modulo chiamato classe, che è uno schema dichiarativo che definisce tipi di oggetti, costituita da nome, attributi, operazioni/metodi. La dichiarazione di classe incapsula la definizione dei campi e dei metodi degli oggetti creabili come istanza di classe. Quattro concetti fondamentali: classe (nome collettivo -dichiarazione di tipo- di tutti gli oggetti che hanno gli stessi metodi e variabili di istanza), oggetto (entità strutturata -codice, dati- e con stato la cui struttura e stato è invisibile all esterno dell oggetto), stato (di un oggetto si accede e manipola mediante messaggi che invocano metodi), variabili di istanza (contenute nell oggetto, 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 del oggetto). Con la programmazione OO si ha: decomposizione di un sistema mediante astrazioni di oggetti; diversa dalla decomposizione funzionale/procedurale. OOA: (analysis) Esaminare e decomporre il problema. OOD: (design)disegnare un modello del problema. OOP: (programming)realizzare il modello. I processi OO hanno tutti la seguente struttura: Elicitazione dei requisiti Identificazione di scenari e casi d uso Estrazione delle classi candidate Identificazione di attributi e metodi Definizione di una gerarchia di classi Costruzione di un modello a oggetti e relazioni Costruzione di un modello di comportamento degli oggetti Revisione dell analisi rispetto ai casi d uso Iterare se necessario. Differenza tra approccio funzionale (non OO) e approccio OO: Componenti sono blocchi funzionali; in OO classi e oggetti. Astrazione e incapsulamento assenti o poveri; in OO sono meccanismi principali. Non modella il dominio del problema; in OO il sistema finale rispecchia il dominio del problema. Sequenziale (thread singolo); in OO c'è concorrenza (thread multipli). Secondo Booch i principali elementi del paradigma OO sono: Astrazione Il progettista crea le classi e gli oggetti; Incapsulamento Information hiding (nascondere i dettagli inessenziali, accesso solo mediante operazioni predefinite); Modularità Decomposizione in moduli ad accoppiamento lasco; Gerarchia ordinamento di astrazioni mediante ereditarietà (uso condiviso di attributi e codice in classi diverse, utile per classificare entità, evitare ridondanze grazie al riuso del codice). Sono da classificarsi elementi minori: Tipaggio (vincoli su classi e oggetti), Concorrenza (Thread multipli), Persistenza (oggetti che sopravvivono nello spazio e nel tempo al programma che li crea). OO garantisce l'information hiding (nascondere i dettagli inessenziali, accesso solo mediante operazioni predefinite; es. invocazione getarea() restiruirà un valore senza mostrare l'implementazione). Un linguaggio di modellazione permette di specificare, visualizzare e documentare un processo di sviluppo OO; i linguaggi di modellazione più usati sono anche standardizzati. I modelli sono strumenti di comunicazione tra cliente e sviluppatori. UML(Unified Modeling Language) è lo standard utilizzato dalla Object Management Group. È un linguaggio con una specifica semantica semiformale che include sintassi astratta, valide regole grammaticali e semantica dinamica. Può essere espresso in diagrammi che abbracciano la gamma di costrutti di un tipico sistema a oggetti. Tra questi diagrammi troviamo il diagramma delle classi (che presenta relazioni di ereditarietà, associazione semantica, composizione e aggregazione), di sequenza (vista temporale dello scambio di messaggi tra classi) e di collaborazione (mostra le interazioni tra gli oggetti), dei casi d'uso. Il diagramma di sequenza e di collaborazione catturano in realtà lo stesso significato, tanto che è facile convertire l'uno nell'altro. Il primo ha un organizzazione molto rigida e pone l'accento sulla sequenza temporale, mentre il secondo tende ad Fig. Diagramma sequenza

23 essere utilizzato in modo più libero e flessibile. La notazione UML, per i diagrammi di classe, offre tre importanti costrutti orientati agli oggetti (uses e extends): eredità (generalizzazione): eredità singole e multiple; associazione generica :(0..*, 1..1, 1..n, ecc...); l'associazione può essere promossa a classe (graficamente la nuova classe NomeAssociazione è collegata alla linea dell'associazione tramite linea tratteggiata) per permettere di collegare ad essa attributi e operazioni; associazione tutto/parte: prende il nome di composizione, dove il tutto è il composto e il parte è il componente, o di aggregazione, dove il tutto è l'aggregato e il parte è il costituente. Il composto non esiste senza i suoi componenti, l'aggregato sì; ciascun componente può essere parte di un solo composto, invece, ciascun Fig. Diagramma di collaborazione costituente può esserlo per più di un aggregato; composizione tipicamente eterogenea, l'aggregazione tende ad essere omogenea. Responsibility-Driven Design Tecnica in cui le responsabilità di un oggetto (conoscere, fare, appòlicare) guidano il suo design, che si concentra sul ruolo di un oggetto e su come il suo comportamento influenza gli altri oggetti. Se si comincia dalle responsabilità di un oggetto risulta più semplice creare la sua interfaccia pubblica, progettare il suo funzionamento interno e tener conto degli eventi da esso riconosciuti. Le varie prospettive di modellazione possono portare a una vista strutturale (componenti), comportamentale (attività), delle responsabilità (scopo entro un sistema). Un approccio per capire quali sono le responsabilità dei vari oggetti prevede l'uso delle schede CRC, dopo aver definito il problema e creato gli scenari d uso (mediante interviste o concentrandosi sulle operazioni principali). Le CRC card sono strutturate in campi: Classe, Supeclasse, Sottoclasse, responsabilità (compiti da eseguire), collaborazioni (altri oggetti che cooperano con questo). Le schede CRC definiscono le classi principali e le loro interazioni, per cui possono essere considrate uno strumento di brainstorming. In seguito verrà usato UML per raffinare e documentare il progetto e per descrivere il progetto ad altri.

24 8. UML e RUP UML è un sistema di notazioni principalmente grafiche (con sintassi, semantica e pragmatica predefinite) per la modellazione OO di sistemi software. UML non è un processo, né è una notazione proprietaria. E' uno standard OMG (Object Management Group), definito mediante un metamodello; è uno standard internazionale, non è proprietà di una singola azienda. UML include: viste (mostrano diverse facce del sistema: utente, strutturale, operazionale, ecc., anche in relazione al processo di sviluppo), diagrammi (grafi che descrivono i contenuti di una vista), elementi di modellazione (costrutti usati nei diagrammi). Aggiungo, rispetto a quando detto prima, un ulteriore diagramma, il diagrammi dei componenti. Illustra l organizzazione e le dipendenze tra i componenti software. Un componente può essere codice sorgente, RunTime (libreria), eseguibile. Fig. Diagramma dei componenti Un componente software è un entità software non banale: un modulo, un package o un sottosistema che abbia una funzione precisa ed un contorno ben delineato, e che possa essere integrato in un architettura ben definita. Concetti chiave in questa definizione: non banale, funzione precisa, contorno ben delineato. Le architetture modulari sono fatte di componenti ben formati. Occorre identificare, progettare, sviluppare e testare i componenti; prima vengono testati da soli, poi integrati e testati nel sistema. I componenti dovrebbero essere riusabili (specialmente se risolvono problemi ricorrenti, sono più che utilità di libreria). Ogni organizzazione costruisce il proprio insieme di componenti riusabili. I componenti si possono comprare già fatti (COTS: Components Off The Shelf): lo sviluppo di un sistema sw allora si riduce a trovare, integrare e testare componenti. Per quanto riguarda la configurazione del sistema, il diagramma di deployment mostra la configurazione a run time degli elementi di calcolo e dei processi software che vivono in essi, inoltre visualizza la distribuzione dei componenti all interno dell azienda. UML, oltre a descrivere sw e servizi per utenti, sviluppatori, dirigenti e clienti, può descrivere l'uso del sw, come funziona, come va costruito e l'accordo (contratto) tra il cliente e lo sviluppatore. Per quanto possa essere essenziale, UML è solo una notazione standard; non specifica affatto il processo, cioè il modo in cui dev essere usata la notazione. È più efficace se viene esplicitamente combinato con un processo di sviluppo; gli inventori di UML raccomandano la sua combinazione con RUP (Objectory = USDP = RUP = UP). Il processo RUP integra due diverse prospettive: una tecnica, che tratta gli aspetti qualitativi, ingegneristici e di metodo di progettazione, l'altra gestionale, che tratta gli aspetti finanziari, strategici, commerciali e umani. Le due prospettive sono rispettivamente articolate su sei e tre core workflow. I workflow vengono suddivisi in (che possono essere estesi o ristretti): workflow di processo Business modeling: attività che modellano l ambito di risoluzione del problema, ovvero l ambiente esterno al sistema da produrre. Requirements: attività che modellano i requisiti del sistema da produrre. Analysis and design: attività di decomposizione del problema e progetto architetturale del sistema. Implementation: attività di progetto dettagliato e codifica del sistema. Test: controllo di qualità, sia a livello di moduli che di integrazione. Deployment: attività di consegna e messa in opera. workflow di supporto

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

Project Management dei Progetti Software

Project Management dei Progetti Software Project Management dei Progetti Software 1 Obiettivi della lezione Il Project Management Tecniche per la stima dei costi sw Misurare le dimensioni di un progetto sw Linee di codice Function Point Stima

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Ciclo e Processo di Sviluppo: approcci tradizionali, evolutivi, agili, free open source software

Ciclo e Processo di Sviluppo: approcci tradizionali, evolutivi, agili, free open source software Ciclo e Processo di Sviluppo: approcci tradizionali, evolutivi, agili, free open source software 1 Ingegneria del software L istituzione e l impiego di principi ingegneristici fondati, allo scopo di ottenere

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:!

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:! Scrum descrizione I Principi di Scrum I Valori dal Manifesto Agile Scrum è il framework Agile più noto. E la sorgente di molte delle idee che si trovano oggi nei Principi e nei Valori del Manifesto Agile,

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras 2 Introduzione Le architetture basate sui servizi (SOA) stanno rapidamente diventando lo standard de facto per lo sviluppo delle applicazioni aziendali.

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

Ricognizione di alcune Best Practice

Ricognizione di alcune Best Practice Linee guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione Manuale di riferimento Ricognizione di alcune Best Practice applicabili

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Business Process Management

Business Process Management Business Process Management Comprendere, gestire, organizzare e migliorare i processi di business Caso di studio a cura della dott. Danzi Francesca e della prof. Cecilia Rossignoli 1 Business process Un

Dettagli

ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali

ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali Cos è un progetto? Un iniziativa temporanea intrapresa per creare un prodotto o un servizio univoco (PMI - Project Management

Dettagli

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Release Management Obiettivi Obiettivo del Release Management è di raggiungere una visione d insieme del cambiamento nei servizi IT e accertarsi che tutti gli aspetti di una release (tecnici e non) siano

Dettagli

Introduzione al Project Management. AIPA Area Monitoraggio e Verifiche

Introduzione al Project Management. AIPA Area Monitoraggio e Verifiche Introduzione al Project Management AIPA Area Monitoraggio e Verifiche Contenuti del corso Impostazione del progetto; Pianificazione delle attività, risorse e costi; Coordinamento e controllo durante le

Dettagli

DataFix. La soluzione innovativa per l'help Desk aziendale

DataFix. La soluzione innovativa per l'help Desk aziendale DataFix D A T A N O S T O P La soluzione innovativa per l'help Desk aziendale La soluzione innovativa per l'help Desk aziendale L a necessità di fornire un adeguato supporto agli utenti di sistemi informatici

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML

INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML Università degli Studi di Parma Dipartimento di Matematica e Informatica Corso di Laurea in Informatica DISPENSE INTRODUTTIVE INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML Prof. Giulio Destri

Dettagli

Configuration Management

Configuration Management Configuration Management Obiettivi Obiettivo del Configuration Management è di fornire un modello logico dell infrastruttura informatica identificando, controllando, mantenendo e verificando le versioni

Dettagli

Presentazione per. «La governance dei progetti agili: esperienze a confronto»

Presentazione per. «La governance dei progetti agili: esperienze a confronto» Presentazione per «La governance dei progetti agili: esperienze a confronto» Pascal Jansen pascal.jansen@inspearit.com Evento «Agile Project Management» Firenze, 6 Marzo 2013 Agenda Due parole su inspearit

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

Problem Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Problem Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Problem Management Obiettivi Obiettivo del Problem Management e di minimizzare l effetto negativo sull organizzazione degli Incidenti e dei Problemi causati da errori nell infrastruttura e prevenire gli

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

Business Intelligence. Il data mining in

Business Intelligence. Il data mining in Business Intelligence Il data mining in L'analisi matematica per dedurre schemi e tendenze dai dati storici esistenti. Revenue Management. Previsioni di occupazione. Marketing. Mail diretto a clienti specifici.

Dettagli

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A.

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A. Università di Venezia Corso di Laurea in Informatica Laboratorio di Informatica Applicata Introduzione all IT Governance Lezione 5 Marco Fusaro KPMG S.p.A. 1 CobiT: strumento per la comprensione di una

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana Storie di successo Microsoft per le Imprese Scenario: Software e Development Settore: Servizi In collaborazione con Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci

Dettagli

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

Executive Master in. Governance dei Progetti e dei Servizi IT GPSIT

Executive Master in. Governance dei Progetti e dei Servizi IT GPSIT Executive Master in Governance dei Progetti e dei Servizi IT GPSIT OBIETTIVI Il Master ha l obiettivo di formare executive e professional nella governance dei progetti e dei servizi IT, integrando quelle

Dettagli

CMMI-Dev V1.3. Capability Maturity Model Integration for Software Development, Version 1.3. Roma, 2012 Ercole Colonese

CMMI-Dev V1.3. Capability Maturity Model Integration for Software Development, Version 1.3. Roma, 2012 Ercole Colonese CMMI-Dev V1.3 Capability Maturity Model Integration for Software Development, Version 1.3 Roma, 2012 Agenda Che cos è il CMMI Costellazione di modelli Approccio staged e continuous Aree di processo Goals

Dettagli

STS. Profilo della società

STS. Profilo della società STS Profilo della società STS, Your ICT Partner Con un solido background accademico, regolari confronti con il mondo della ricerca ed esperienza sia nel settore pubblico che privato, STS è da oltre 20

Dettagli

Intrusion Detection System

Intrusion Detection System Capitolo 12 Intrusion Detection System I meccanismi per la gestione degli attacchi si dividono fra: meccanismi di prevenzione; meccanismi di rilevazione; meccanismi di tolleranza (recovery). In questo

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

Dettagli

REALIZZARE UN MODELLO DI IMPRESA

REALIZZARE UN MODELLO DI IMPRESA REALIZZARE UN MODELLO DI IMPRESA - organizzare e gestire l insieme delle attività, utilizzando una piattaforma per la gestione aziendale: integrata, completa, flessibile, coerente e con un grado di complessità

Dettagli

Informatica. Scopo della lezione

Informatica. Scopo della lezione 1 Informatica per laurea diarea non informatica LEZIONE 1 - Cos è l informatica 2 Scopo della lezione Introdurre le nozioni base della materia Definire le differenze tra hardware e software Individuare

Dettagli

Accuratezza di uno strumento

Accuratezza di uno strumento Accuratezza di uno strumento Come abbiamo già accennato la volta scora, il risultato della misurazione di una grandezza fisica, qualsiasi sia lo strumento utilizzato, non è mai un valore numerico X univocamente

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

Dettagli

white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo

white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo White paper La Process Intelligence migliora le prestazioni operative del settore assicurativo Pagina 2 Sintesi

Dettagli

DigitPA LINEE GUIDA. Centro di competenza del riuso. DigitPA 00137 Roma - viale Marx, 43 Pagina 1 di 140

DigitPA LINEE GUIDA. Centro di competenza del riuso. DigitPA 00137 Roma - viale Marx, 43 Pagina 1 di 140 LINEE GUIDA PER L INSERIMENTO ED IL RIUSO DI PROGRAMMI INFORMATICI O PARTI DI ESSI PUBBLICATI NELLA BANCA DATI DEI PROGRAMMI INFORMATICI RIUTILIZZABILI DI DIGITPA DigitPA 00137 Roma - viale Marx, 43 Pagina

Dettagli

Corso Base ITIL V3 2008

Corso Base ITIL V3 2008 Corso Base ITIL V3 2008 PROXYMA Contrà San Silvestro, 14 36100 Vicenza Tel. 0444 544522 Fax 0444 234400 Email: proxyma@proxyma.it L informazione come risorsa strategica Nelle aziende moderne l informazione

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA

LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA ROMA 20-22 OTTOBRE 2014 RESIDENZA DI RIPETTA - VIA DI RIPETTA,

Dettagli

Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI

Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI Risposte ai quesiti ricevuti per l Avviso di gara per la realizzazione del sistema informatico per la gestione richieste di finanziamento FAPISI Forniamo in questo articolo le risposte ai 53 quesiti ricevuti

Dettagli

White Paper. Operational DashBoard. per una Business Intelligence. in real-time

White Paper. Operational DashBoard. per una Business Intelligence. in real-time White Paper Operational DashBoard per una Business Intelligence in real-time Settembre 2011 www.axiante.com A Paper Published by Axiante CAMBIARE LE TRADIZIONI C'è stato un tempo in cui la Business Intelligence

Dettagli

GESTIONE ATTREZZATURE

GESTIONE ATTREZZATURE SOLUZIONE COMPLETA PER LA GESTIONE DELLE ATTREZZATURE AZIENDALI SWSQ - Solution Web Safety Quality srl Via Mons. Giulio Ratti, 2-26100 Cremona (CR) P. Iva/C.F. 06777700961 - Cap. Soc. 10.000,00 I.V. -

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI Prefazione Autori XIII XVII Capitolo 1 Sistemi informativi aziendali 1 1.1 Introduzione 1 1.2 Modello organizzativo 3 1.2.1 Sistemi informativi

Dettagli

IT Service Management

IT Service Management IT Service Management L'importanza dell'analisi dei processi nelle grandi e medie realtà italiane Evento Business Strategy 2.0 Firenze 25 settembre 2012 Giovanni Sadun Agenda ITSM: Contesto di riferimento

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA

THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA SAP World Tour 2007 - Milano 11-12 Luglio 2007 THUN con ARIS: dall'ottimizzazione dei processi verso l enterprise SOA Agenda Presentazione Derga Consulting Enterprise SOA Allineamento Processi & IT Il

Dettagli

t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence.

t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence. t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence. Per le aziende manifatturiere, oggi e sempre più nel futuro individuare ed eliminare gli

Dettagli

Costruire uno Spin-Off di Successo. Non fidarsi mai dei professori

Costruire uno Spin-Off di Successo. Non fidarsi mai dei professori Costruire uno Spin-Off di Successo Non fidarsi mai dei professori Spin-Off da Università: Definizione Lo Spin-Off da Università è in generale un processo che, partendo da una tecnologia disruptiva sviluppata

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

Progetto BPR: Business Process Reengineering

Progetto BPR: Business Process Reengineering Progetto BPR: Business Process Reengineering Riflessioni frutto di esperienze concrete PER LA CORRETTA INTERPRETAZIONE DELLE PAGINE SEGUENTI SI DEVE TENERE CONTO DI QUANTO ILLUSTRATO ORALMENTE Obiettivo

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

La Valutazione Euristica

La Valutazione Euristica 1/38 E un metodo ispettivo di tipo discount effettuato da esperti di usabilità. Consiste nel valutare se una serie di principi di buona progettazione sono stati applicati correttamente. Si basa sull uso

Dettagli

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Oggi più che mai, le aziende italiane sentono la necessità di raccogliere,

Dettagli

Esempi di algoritmi. Lezione III

Esempi di algoritmi. Lezione III Esempi di algoritmi Lezione III Scopo della lezione Implementare da zero algoritmi di media complessità. Verificare la correttezza di un algoritmo eseguendolo a mano. Imparare a valutare le prestazioni

Dettagli

Dalla Mappatura dei Processi al Business Process Management

Dalla Mappatura dei Processi al Business Process Management Dalla Mappatura dei Processi al Business Process Management Romano Stasi Responsabile Segreteria Tecnica ABI Lab Roma, 4 dicembre 2007 Agenda Il percorso metodologico Analizzare per conoscere: la mappatura

Dettagli

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis 2 Intervento immediato con Bosch Intelligent Video Analysis Indipendentemente da quante telecamere il sistema utilizza, la sorveglianza

Dettagli

UNIVERSITÀ DEGLI STUDI DI GENOVA

UNIVERSITÀ DEGLI STUDI DI GENOVA UNIVERSITÀ DEGLI STUDI DI GENOVA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA Prova Finale GESTIONE DELLA TRANSIZIONE SECONDO LO STANDARD ITIL ITIL SERVICE TRANSITION

Dettagli

COME FRODE. la possibilità propri dati. brevissimo. Reply www.reply.eu

COME FRODE. la possibilità propri dati. brevissimo. Reply www.reply.eu FRAUD MANAGEMENT. COME IDENTIFICARE E COMB BATTERE FRODI PRIMA CHE ACCADANO LE Con una visione sia sui processi di business, sia sui sistemi, Reply è pronta ad offrire soluzioni innovative di Fraud Management,

Dettagli

DI D AGRA R MM M I M A BLOCC C H C I TEORI R A E D D E SERC R I C ZI 1 1

DI D AGRA R MM M I M A BLOCC C H C I TEORI R A E D D E SERC R I C ZI 1 1 DIAGRAMMI A BLOCCHI TEORIA ED ESERCIZI 1 1 Il linguaggio dei diagrammi a blocchi è un possibile formalismo per la descrizione di algoritmi Il diagramma a blocchi, o flowchart, è una rappresentazione grafica

Dettagli

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult KM, ECM e BPM per creare valore nell impresa Giovanni Marrè Amm. Del., it Consult Terminologia Ci sono alcuni termini che, a vario titolo, hanno a che fare col tema dell intervento KM ECM BPM E20 Enterprise

Dettagli

Storia ed evoluzione dei sistemi ERP

Storia ed evoluzione dei sistemi ERP Storia ed evoluzione dei sistemi ERP In questo breve estratto della tesi si parlerà dei sistemi ERP (Enterprise Resource Planning) utilizzabili per la gestione delle commesse; questi sistemi utilizzano

Dettagli

IT Service Management, le best practice per la gestione dei servizi

IT Service Management, le best practice per la gestione dei servizi Il Framework ITIL e gli Standard di PMI : : possibili sinergie Milano, Venerdì, 11 Luglio 2008 IT Service Management, le best practice per la gestione dei servizi Maxime Sottini Slide 1 Agenda Introduzione

Dettagli

Abstract Data Type (ADT)

Abstract Data Type (ADT) Abstract Data Type Pag. 1/10 Abstract Data Type (ADT) Iniziamo la nostra trattazione presentando una nozione che ci accompagnerà lungo l intero corso di Laboratorio Algoritmi e Strutture Dati: il Tipo

Dettagli

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali LAVORO DI GRUPPO Caratteristiche dei gruppi di lavoro transnazionali Esistono molti manuali e teorie sulla costituzione di gruppi e sull efficacia del lavoro di gruppo. Un coordinatore dovrebbe tenere

Dettagli

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali DynDevice ECM La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali Presentazione DynDevice ECM Cos è DynDevice ICMS Le soluzioni di DynDevice

Dettagli

Integrazione. Ecad. Mcad. Ecad - MENTOR GRAPHICS

Integrazione. Ecad. Mcad. Ecad - MENTOR GRAPHICS Integrazione Ecad Mcad Ecad - MENTOR GRAPHICS MENTOR GRAPHICS - PADS La crescente complessità del mercato della progettazione elettronica impone l esigenza di realizzare prodotti di dimensioni sempre più

Dettagli

John Dewey. Le fonti di una scienza dell educazione. educazione

John Dewey. Le fonti di una scienza dell educazione. educazione John Dewey Le fonti di una scienza dell educazione educazione 1929 L educazione come scienza indipendente Esiste una scienza dell educazione? Può esistere una scienza dell educazione? Ṫali questioni ineriscono

Dettagli

Business Process Management

Business Process Management Corso di Certificazione in Business Process Management Progetto Didattico 2015 con la supervisione scientifica del Dipartimento di Informatica Università degli Studi di Torino Responsabile scientifico

Dettagli

Progettazione Orientata agli Oggetti

Progettazione Orientata agli Oggetti Progettazione Orientata agli Oggetti Sviluppo del software Ciclo di vita del software: comprende tutte le attività dall analisi iniziale fino all obsolescenza (sviluppo, aggiornamento, manutenzione) Procedimento

Dettagli

Ottimizzazione della gestione del data center con Microsoft System Center

Ottimizzazione della gestione del data center con Microsoft System Center Ottimizzazione della gestione del data center con Microsoft System Center Declinazione di responsabilità e informazioni sul copyright Le informazioni contenute nel presente documento rappresentano le conoscenze

Dettagli

Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate

Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate 6.1 Metodi per lo sviluppo di nuovi prodotti (MSNP) Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate Questo capitolo presenta alcune metodologie per gestire al meglio

Dettagli

IT Service Management

IT Service Management IT Service Management ITIL: I concetti chiave ed il livello di adozione nelle aziende italiane Matteo De Angelis, itsmf Italia (I) 1 Chi è itsmf italia 12 th May 2011 - Bolzano itsmf (IT Service Management

Dettagli

Energy Studio Manager Manuale Utente USO DEL SOFTWARE

Energy Studio Manager Manuale Utente USO DEL SOFTWARE Energy Studio Manager Manuale Utente USO DEL SOFTWARE 1 ANALYSIS.EXE IL PROGRAMMA: Una volta aperto il programma e visualizzato uno strumento il programma apparirà come nell esempio seguente: Il programma

Dettagli

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software.

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software. Generalità Definizione Un firewall è un sistema che protegge i computer connessi in rete da attacchi intenzionali mirati a compromettere il funzionamento del sistema, alterare i dati ivi memorizzati, accedere

Dettagli

Classificazioni dei sistemi di produzione

Classificazioni dei sistemi di produzione Classificazioni dei sistemi di produzione Sistemi di produzione 1 Premessa Sono possibili diverse modalità di classificazione dei sistemi di produzione. Esse dipendono dallo scopo per cui tale classificazione

Dettagli

L 8 maggio 2002 il Ministero

L 8 maggio 2002 il Ministero > > > > > Prima strategia: ascoltare le esigenze degli utenti, semplificare il linguaggio e la navigazione del sito. Seconda: sviluppare al nostro interno le competenze e le tecnologie per gestire in proprio

Dettagli

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto

Scheda descrittiva del programma. Open-DAI. ceduto in riuso. CSI-Piemonte in rappresentanza del Consorzio di progetto Scheda descrittiva del programma Open-DAI ceduto in riuso CSI-Piemonte in rappresentanza del Consorzio di progetto Agenzia per l Italia Digitale - Via Liszt 21-00144 Roma Pagina 1 di 19 1 SEZIONE 1 CONTESTO

Dettagli

LE NOVITÀ DELL EDIZIONE 2011 DELLO STANDARD ISO/IEC 20000-1 E LE CORRELAZIONI CON IL FRAMEWORK ITIL

LE NOVITÀ DELL EDIZIONE 2011 DELLO STANDARD ISO/IEC 20000-1 E LE CORRELAZIONI CON IL FRAMEWORK ITIL Care Colleghe, Cari Colleghi, prosegue la nuova serie di Newsletter legata agli Schemi di Certificazione di AICQ SICEV. Questa volta la pillola formativa si riferisce alle novità dell edizione 2011 dello

Dettagli

Analisi di Software Open Source per Project Management con logia PHP Relazione di Tirocinio

Analisi di Software Open Source per Project Management con logia PHP Relazione di Tirocinio Analisi di Software Open Source per Project Management con logia PHP Relazione di Tirocinio Umberto Sartore - 578209 Relatore: Prof. Ennio Buro UNIVERSITA DEGLI STUDI DI PADOVA FACOLTA DI INGEGNERIA CORSO

Dettagli

Energy risk management

Energy risk management Il sistema di supporto alle tue decisioni Energy risk management Un approccio orientato agli attori M.B.I. Srl, Via Francesco Squartini 7-56121 Pisa, Italia - tel. 050 3870888 - fax. 050 3870808 www.powerschedo.it

Dettagli

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

Dettagli

How to Develop Accessible Linux Applications

How to Develop Accessible Linux Applications How to Develop Accessible Linux Applications Sharon Snider Copyright 2002 IBM Corporation v1.1, 2002-05-03 Diario delle Revisioni Revisione v1.1 2002-05-03 Revisionato da: sds Convertito in DocBook XML

Dettagli

Processi ITIL. In collaborazione con il nostro partner:

Processi ITIL. In collaborazione con il nostro partner: Processi ITIL In collaborazione con il nostro partner: NetEye e OTRS: la piattaforma WÜRTHPHOENIX NetEye è un pacchetto di applicazioni Open Source volto al monitoraggio delle infrastrutture informatiche.

Dettagli

Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI

Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI Business Intelligence RENDE STRATEGICHE LE INFORMAZIONI CSC ritiene che la Business Intelligence sia un elemento strategico e fondamentale che, seguendo

Dettagli

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

Dettagli

Gli Standard hanno lo scopo di:

Gli Standard hanno lo scopo di: STANDARD INTERNAZIONALI PER LA PRATICA PROFESSIONALE DELL INTERNAL AUDITING (STANDARD) Introduzione agli Standard L attività di Internal audit è svolta in contesti giuridici e culturali diversi, all interno

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

Capitolo 9: PROPAGAZIONE DEGLI ERRORI

Capitolo 9: PROPAGAZIONE DEGLI ERRORI Capitolo 9: PROPAGAZIOE DEGLI ERRORI 9.1 Propagazione degli errori massimi ella maggior parte dei casi le grandezze fisiche vengono misurate per via indiretta. Il valore della grandezza viene cioè dedotto

Dettagli

Gara LOCO- Richiesta di chiarimenti

Gara LOCO- Richiesta di chiarimenti Domanda 1 Si chiede di specificare il numero orientativo dei partecipanti ai corsi di formazione diviso per tipologia (dirigenti, utenti e personale informatico) (cfr. Capitolato capitolo 10). Risposta

Dettagli

PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI?

PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI? PUBLIC, PRIVATE O HYBRID CLOUD: QUAL È IL TIPO DI CLOUD OTTIMALE PER LE TUE APPLICAZIONI? Le offerte di public cloud proliferano e il private cloud è sempre più diffuso. La questione ora è come sfruttare

Dettagli