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

Ciclo di vita del progetto

Ciclo di vita del progetto IT Project Management Lezione 2 Ciclo di vita del progetto Federica Spiga A.A. 2009-2010 1 Ciclo di vita del progetto Il ciclo di vita del progetto definisce le fasi che collegano l inizio e la fine del

Dettagli

Software project management. www.vincenzocalabro.it

Software project management. www.vincenzocalabro.it Software project management Software project management Sono le attività necessarie per assicurare che un prodotto software sia sviluppato rispettando le scadenze fissate rispondendo a determinati standard

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

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi metodologie a.a. 2003-2004 1 metodologia una serie di linee guida per raggiungere certi obiettivi più formalmente: un processo da seguire documenti o altri elaborati da produrre usando linguaggi più o

Dettagli

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 2. Ciclo di Vita e Processi di

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

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

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

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

Gestione di progetto: pianificazione. Introduzione: dove siamo? Introduzione: pianificazione. Simona Bernardi

Gestione di progetto: pianificazione. Introduzione: dove siamo? Introduzione: pianificazione. Simona Bernardi Gestione di progetto: pianificazione Simona Bernardi Corso di Ingegneria del Software 04/ 05 Prof.Susanna Donatelli Introduzione: dove siamo? Gestione di progetto: Pianificazione Monitoraggio e controllo

Dettagli

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

02: Project Management

02: Project Management 02: Project Management Le tre P del project management Persone motivate / esperte SEI PM-CMM (People Management Capability Maturity Model) assunzione / selezione addestramento / cultura di gruppo stipendio

Dettagli

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al.

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al. Modello Code and fix Processo parte III Leggere Sez. 7.4 Ghezzi et al. Modello iniziale Iterazione di due passi scrittura del codice correzione degli errori Problemi: dopo una serie di cambiamenti, la

Dettagli

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard Quality gate Nei punti chiave del processo di sviluppo del software, viene integrato un insieme di quality gate per monitorare la qualità del prodotto intermedio prima che quest ultimo possa passare al

Dettagli

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 15: P.M.: metodologie di progetto Prof.ssa R. Folgieri email: folgieri@dico.unimi.it folgieri@mtcube.com 1 Modelli di conduzione

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Leveling delle attività

Leveling delle attività Leveling delle attività Metodi per risolvere i conflitti di allocazione delle attività Allocare in modo non-uniforme Ritardare un attività Prima le attività con slack più alto Nel caso di attività con

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

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

3. SOFTWARE MANAGEMENT

3. SOFTWARE MANAGEMENT 3. SOFTWARE MANAGEMENT Introdurre caratteristiche e problematiche della direzione di progetto software (software management) Discutere la pianificazione di un progetto e la temporizzazione (scheduling)

Dettagli

Introduzione all Ingegneria del Software

Introduzione all Ingegneria del Software Introduzione all Ingegneria del Software Alessandro Martinelli alessandro.martinelli@unipv.it 10 Dicembre 2013 Introduzione all Ingegneria del Software Ingegneria del Software Modelli di Sviluppo del Software

Dettagli

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt IT Project Management Lezione 3 Scope Management Federica Spiga A.A. 2009-2010 1 Check list del PM Identificare i requisiti del cliente Monitoring del progetto (Earned Value) Identificare i deliverable

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

13. Ciclo di Vita e Processi di Sviluppo

13. Ciclo di Vita e Processi di Sviluppo 13. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 13. Ciclo di Vita e Processi

Dettagli

Qualità del software. Tecniche di Programmazione 2009/10. Giovanni A. Cignoni - http://www.di.unipi.it/~giovanni/ 1. contenuti. definizione di qualità

Qualità del software. Tecniche di Programmazione 2009/10. Giovanni A. Cignoni - http://www.di.unipi.it/~giovanni/ 1. contenuti. definizione di qualità Qualità del software Tecniche di Programmazione Lez. 05 Università di Firenze a.a. 2009/10, I semestre 1/33 contenuti Qualità? Definizioni Il prodotto software Modelli della qualità per il sw: ISO/IEC

Dettagli

CONCETTI DI BASE PER LA QUALITA

CONCETTI DI BASE PER LA QUALITA CONCETTI DI BASE PER LA QUALITA Misura: è una funzione m: A -> B che associa ad ogni attributo A di un osservabile nel mondo reale o empirico (dominio) un oggetto formale B nel mondo matematico (range);

Dettagli

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo Luca Cabibbo Analisi e Progettazione del Software Sviluppo iterativo, evolutivo e agile Capitolo 2 marzo 2015 Lo sviluppo iterativo dovrebbe essere utilizzato solo per i progetti che si desidera che vadano

Dettagli

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti Sviluppo Agile [Cockburn 2002] Extreme Programming (XP) [Beck 2000] Sono più importanti auto-organizzazione, collaborazione, comunicazione tra membri del team e adattabilità del prodotto rispetto ad ordine

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

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

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo

Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo Progetto software 2008/2009 Docente Marianna Nicolosi Asmundo Obiettivi del corso Coinvolgervi nello sviluppo di un progetto software in cui mettere a frutto le conoscenze che avete acquisito durante i

Dettagli

Gestione dello sviluppo software Modelli Agili

Gestione dello sviluppo software Modelli Agili Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi A4_3 V1.1 Gestione dello sviluppo software Modelli Agili Il contenuto del documento è liberamente utilizzabile dagli

Dettagli

GESTIONE DEI PROGETTI

GESTIONE DEI PROGETTI GESTIONE DEI PROGETTI Problema del management Fallimento negli anni 60, inizio 70 Non tanto dovuto alla competenza Un buon management non garantisce il successo ma un cattivo management risulta spesso

Dettagli

GESTIONE DEI PROGETTI. Inizio

GESTIONE DEI PROGETTI. Inizio GESTIONE DEI PROGETTI Problema del management Fallimento negli anni 60, inizio 70 Non tanto dovuto alla competenza Un buon management non garantisce il successo ma un cattivo management risulta spesso

Dettagli

Obiettivi della Lezione. Project Management. Software Project Management. Che cos è un progetto

Obiettivi della Lezione. Project Management. Software Project Management. Che cos è un progetto Project Management Dott. Andrea F. Abate e-mail: abate@unisa.it Web: http://www.dmi.unisa.it/people/abate Gestione di Progetti Software: Pianificazione delle attività e rappresentazioni grafiche Obiettivi

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Gestione di progetto. Gestione di progetto. Criticità. Fattori di rischio. Fondamenti. Istanziare processi nel progetto

Gestione di progetto. Gestione di progetto. Criticità. Fattori di rischio. Fondamenti. Istanziare processi nel progetto Criticità Gestione di progetto Ingegneria del Software V. Ambriola, G.A. Cignoni, C. Montangero, L. Semini Aggiornamenti: T. Vardanega (UniPD) Il prodotto SW è intangibile e (troppo) flessibile Al software

Dettagli

Piano di gestione della qualità

Piano di gestione della qualità Piano di gestione della qualità Pianificazione della qualità Politica ed obiettivi della qualità Riferimento ad un eventuale modello di qualità adottato Controllo della qualità Procedure di controllo.

Dettagli

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 12: Metodologie: controllo qualità P.M. Fase 3-4: tracking di progetto, introduzione Prof.ssa R. Folgieri email: folgieri@dico.unimi.it

Dettagli

Project Management dei Progetti Software. Prof. Paolo Ciancarini! Corso di Ingegneria del Software! CdL Informatica! Università di Bologna

Project Management dei Progetti Software. Prof. Paolo Ciancarini! Corso di Ingegneria del Software! CdL Informatica! Università di Bologna Project Management dei Progetti Software Prof. Paolo Ciancarini! Corso di Ingegneria del Software! CdL Informatica! Università di Bologna 1 Obiettivi della lezione Il Project Management Tecniche per la

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Gestione. di progetto. Gestione di progetto. IS 2011 - Ingegneria del Software 1. Contenuti. Fondamenti. Criticità. Gestione dei rischi 1

Gestione. di progetto. Gestione di progetto. IS 2011 - Ingegneria del Software 1. Contenuti. Fondamenti. Criticità. Gestione dei rischi 1 Contenuti Gestione di progetto Ruoli professionali Pianificazione di progetto Ingegneria del Software Stima dei costi di progetto V. Ambriola, G.A. Cignoni, C. Montangero, L. Semini Seminario: rischi di

Dettagli

Ciclo di vita dimensionale

Ciclo di vita dimensionale aprile 2012 1 Il ciclo di vita dimensionale Business Dimensional Lifecycle, chiamato anche Kimball Lifecycle descrive il framework complessivo che lega le diverse attività dello sviluppo di un sistema

Dettagli

Corso di Progettazione di sistemi multimediali

Corso di Progettazione di sistemi multimediali Corso di Progettazione di sistemi multimediali prof. Pierluigi Feliciati a.a.2012/13 Modulo 0 Progettare, sistemi, multimedialità: Definizioni, strumenti, ciclo di vita dei progetti, figure professionali

Dettagli

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso Agile mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software Sviluppo Agile: metaprocesso Molti progetti software falliscono Sì parte dagli anni 2000 Millennium

Dettagli

GUFPI-ISMA. Evoluzione delle Linee Guida: l utilizzo contrattuale dei Function Points. Roberto Meli

GUFPI-ISMA. Evoluzione delle Linee Guida: l utilizzo contrattuale dei Function Points. Roberto Meli GUFPI-ISMA Evoluzione delle Linee Guida: l utilizzo contrattuale dei Function Points Roberto Meli Coordinatore Consiglio Direttivo GUFPI-ISMA 2 Perché era necessario intervenire? I contratti per il software

Dettagli

1. L Ingegneria del Software

1. L Ingegneria del Software 1. L Ingegneria del Software Obiettivi della lezione: Definire cosa si intende per Ingegneria del Software Discutere i concetti di prodotto software e di processo software Spiegare il concetto di visibilità

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Ingegneria del Software MINR Giuseppe Santucci. 05 - Il metodo dei FP

Ingegneria del Software MINR Giuseppe Santucci. 05 - Il metodo dei FP Ingegneria del Software MINR Giuseppe Santucci 05 - Il metodo dei FP 05fp.1 Metriche relative al sw Dirette misure effettuabili direttamente sul codice LOC (Line Of Code) Indice di McCabe... misure effettuabili

Dettagli

Il PROCESSO UNIFICATO

Il PROCESSO UNIFICATO Corsi di laurea triennale/magistrale in Ingegneria Informatica Corsi di Ingegneria del software, Modellazione ed Implementazione di un Sistema Software per la gestione informatizzata di un ristorante:

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

Dettagli

Processi per lo sviluppo rapido del software

Processi per lo sviluppo rapido del software Lezione 3 Processi per lo sviluppo rapido del software Sviluppo Rapido del Software Slide 1 Riferimenti bibliografici I. Sommerville Ingegneria del Software 8a edizione Cap.17 R. Pressman- Principi di

Dettagli

Software Project Management Plan 1.0

Software Project Management Plan 1.0 Software Project Management Plan 1.0 17 maggio 2010 Gruppo CiDeFaRo Progetto di Laboratorio Sistemi e Processi Organizzativi 2010 ALMA MATER STUDIORUM - Universitá di Bologna Facolt di Scienze Matematiche

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

Sistemi Informativi I Lezioni di Ingegneria del Software

Sistemi Informativi I Lezioni di Ingegneria del Software 4 Codifica, Test e Collaudo. Al termine della fase di progettazione, a volte anche in parallelo, si passa alla fase di codifica e successivamente alla fase di test e collaudo. In questa parte viene approfondita

Dettagli

Laboratorio di Progettazione di Sistemi Software Introduzione

Laboratorio di Progettazione di Sistemi Software Introduzione Laboratorio di Progettazione di Sistemi Software Introduzione Valentina Presutti (A-L) Riccardo Solmi (M-Z) Indice degli argomenti Introduzione all Ingegneria del Software UML Design Patterns Refactoring

Dettagli

Ingegneria del Software 2

Ingegneria del Software 2 Politecnico di Milano Anno Accademico 2010/2011 Ingegneria del Software 2 Corso della Prof.ssa Elisabetta Di Nitto Stefano Invernizzi Facoltà di Ingegneria dell Informazione Corso di Laurea Magistrale

Dettagli

Il modello di ottimizzazione SAM

Il modello di ottimizzazione SAM Il modello di ottimizzazione control, optimize, grow Il modello di ottimizzazione Il modello di ottimizzazione è allineato con il modello di ottimizzazione dell infrastruttura e fornisce un framework per

Dettagli

Gestione dei Progetti (2005-2006)

Gestione dei Progetti (2005-2006) Gestione dei Progetti (2005-2006) Alessandro Agnetis DII Università di Siena (Alcune delle illustrazioni contenute nella presentazione sono tratte da PMBOK, a guide to the Project Management Body of Knowledge,

Dettagli

Ingegneria del Software

Ingegneria del Software Ingegneria del Software Processi di Sviluppo Agile Origini dello Sviluppo Agile Proposta di un gruppo di sviluppatori che rilevava una serie di criticità degli approcci convenzionali: Troppa rigidità dei

Dettagli

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

Dettagli

I Modelli della Ricerca Operativa

I Modelli della Ricerca Operativa Capitolo 1 I Modelli della Ricerca Operativa 1.1 L approccio modellistico Il termine modello è di solito usato per indicare una costruzione artificiale realizzata per evidenziare proprietà specifiche di

Dettagli

Corso di Ingegneria del Software. Metriche Parte I

Corso di Ingegneria del Software. Metriche Parte I Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca mario.vacca1@istruzione.it Concetti di base Metriche Sommario 1. Concetti di base 2. METRICHE DIMENSIONALI 3. 4. METRICHE STRUTTURALI 5. Bibliografia

Dettagli

Lezione 1 Ingegneria del Software II- Introduzione e Motivazione. Ingegneria del Software 2 Introduzione e Richiami 1

Lezione 1 Ingegneria del Software II- Introduzione e Motivazione. Ingegneria del Software 2 Introduzione e Richiami 1 Lezione 1 Ingegneria del Software II- Introduzione e Motivazione Ingegneria del Software 2 Introduzione e Richiami 1 Riferimenti bibliografici I. Sommerville Ingegneria del Software 8a edizione Cap.1 R.

Dettagli

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

Dettagli

4. Requisiti del Software

4. Requisiti del Software 4. Requisiti del Software Cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 4. Requisiti del Software 1 / 35 Sommario 1 Generalità 2 Categorizzazione

Dettagli

Ingegneria del Software. Processi di Sviluppo

Ingegneria del Software. Processi di Sviluppo Ingegneria del Software Processi di Sviluppo Ingegneria del Software: Tecnologia Stratificata tools metodi processi Focus sulla qualità Ingegneria del Software: Tecnologia Stratificata (2) Qualità Elemento

Dettagli

5. Requisiti del Software II

5. Requisiti del Software II 5. Requisiti del Software II Come scoprire cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 5. Requisiti del Software II 1 / 42 Sommario 1 Generalità

Dettagli

Processi di Sviluppo Software Introduzione. Giuseppe Calavaro

Processi di Sviluppo Software Introduzione. Giuseppe Calavaro Processi di Sviluppo Software Introduzione Giuseppe Calavaro Processi di sviluppo software - Agenda Differenza tra Programmazione e Progettazione SW I Processi di Sviluppo Software Waterfall Spirale RUP

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia BANDO ACQUISIZIONI Prodotti Software ALLEGATO 6.3 Capitolato Tecnico Piattaforma per l Analisi e la Progettazione di alto livello del Software Allegato 6.3: capitolato tecnico Pag. 1 1 Ambiente di Analisi

Dettagli

Corso di Ingegneria del Software. Modelli di produzione del software

Corso di Ingegneria del Software. Modelli di produzione del software Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca mario.vacca1@istruzione.it 1. Concetti di base Sommario 2. Modelli del ciclo vita del software 2.1 Modello a cascata 2.2 Modelli incrementali

Dettagli

Ciclo di vita del software

Ciclo di vita del software Ciclo di vita del software Da Wikipedia, l'enciclopedia libera. L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività

Dettagli

Pattern Architetturali e Analisi Architetturale

Pattern Architetturali e Analisi Architetturale Pattern Architetturali e Analisi Architetturale Ingegneria del Software parte II Andrea Bei Pattern Architetturali Pattern Architetturale Descrive il modello organizzativo strutturale di un sistema software

Dettagli

Indice. Prefazione all edizione italiana

Indice. Prefazione all edizione italiana Indice Prefazione all edizione italiana XV Capitolo 1 Il software e l ingegneria del software 1 1.1 L evoluzione del ruolo del software 3 1.2 Il software 5 1.3 La natura mutevole del software 8 1.4 Il

Dettagli

Fondamenti di Informatica 7. Linguaggi di programmazione

Fondamenti di Informatica 7. Linguaggi di programmazione I linguaggi di alto livello Fondamenti di Informatica 7. Linguaggi di programmazione Introduzione alla programmazione Caratteristiche dei linguaggi di programmazione I linguaggi di programmazione di alto

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

extreme Programming in un curriculum universitario

extreme Programming in un curriculum universitario extreme Programming in un curriculum universitario Lars Bendix Department of Computer Science Lund Institute of Technology Sweden Università di Bologna, 18 giugno, 2002 Extreme Programming On-site customer

Dettagli

Gestione di progetti (software)

Gestione di progetti (software) Gestione di progetti (software) Tecniche di Programmazione Lez. 03 Università di Firenze a.a. 2009/10, I semestre 1/25 Contenuti Gestione di progetto Ruoli professionali Pianificazione di progetto Stima

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

Stima dell'effort. IT Project Management. Lezione 6 Stima dell effort Federica Spiga. Monitoring del progetto (Earned Value)

Stima dell'effort. IT Project Management. Lezione 6 Stima dell effort Federica Spiga. Monitoring del progetto (Earned Value) IT Project Management Lezione 6 Stima dell effort Federica Spiga A.A. 2009-2010 1 Check list del PM Identificare i requisiti del cliente Monitoring del progetto (Earned Value) Identificare i deliverable

Dettagli

Gestire un progetto di introduzione di sistemi informativi di SCM. 1 Marco Bettucci Gestione della produzione II - LIUC

Gestire un progetto di introduzione di sistemi informativi di SCM. 1 Marco Bettucci Gestione della produzione II - LIUC Gestire un progetto di introduzione di sistemi informativi di SCM 1 Che cos è un progetto? Una serie complessa di attività in un intervallo temporale definito... finalizzate al raggiungimento di obiettivi

Dettagli

Corso di Sistemi di elaborazione delle informazioni

Corso di Sistemi di elaborazione delle informazioni Corso di Sistemi di elaborazione delle informazioni Biacco Sabrina ENTERPRISE RESOURCE PLANNING Gli ERP sono delle soluzioni applicative in grado di coordinare l'insieme delle attività aziendali automatizzando

Dettagli

Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software. Gestione di progetto. Marina Mongiello

Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software. Gestione di progetto. Marina Mongiello Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del Gestione di progetto Contenuti Gestione di progetto Ruoli professionali Pianificazione di progetto Stima dei costi di progetto Rischi

Dettagli

Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza. Roberto Ugolini roberto.ugolini@postecom.it

Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza. Roberto Ugolini roberto.ugolini@postecom.it Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza Roberto Ugolini 1 Il processo di sviluppo sicuro del codice (1/2) Il processo di sviluppo sicuro del codice () è composto

Dettagli

Lista delle descrizioni dei Profili

Lista delle descrizioni dei Profili Lista delle descrizioni dei Profili La seguente lista dei Profili Professionali ICT è stata definita dal CEN Workshop on ICT Skills nell'ambito del Comitato Europeo di Standardizzazione. I profili fanno

Dettagli

Modelli di processo per lo sviluppo del software: modelli lineari e modelli iterativi

Modelli di processo per lo sviluppo del software: modelli lineari e modelli iterativi Modelli di processo per lo sviluppo del software: modelli lineari e modelli iterativi Prof. Paolo Ciancarini Corso di Ingegneria del Software CdL Informatica Università di Bologna Obiettivi di questa lezione

Dettagli

La portata del software

La portata del software La portata del software Portata Contesto. In che modo il software in costruzione si inserirà nel sistema, prodotto o contesto aziendale esistente e quali vincoli impone il contesto? Obiettivi relativi

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

ISTITUTO TECNICO ECONOMICO MOSSOTTI

ISTITUTO TECNICO ECONOMICO MOSSOTTI CLASSE III INDIRIZZO S.I.A. UdA n. 1 Titolo: conoscenze di base Conoscenza delle caratteristiche dell informatica e degli strumenti utilizzati Informatica e sistemi di elaborazione Conoscenza delle caratteristiche

Dettagli

Software solido e usabile: come integrare ingegneria dell usabilità e del software

Software solido e usabile: come integrare ingegneria dell usabilità e del software Software solido e usabile: come integrare ingegneria dell usabilità e del software Giorgio Brajnik e Andrea Baruzzo Dip. di Matematica e Informatica Università di Udine e Interaction Design Solutions srl

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

Linguaggi e Paradigmi di Programmazione

Linguaggi e Paradigmi di Programmazione Linguaggi e Paradigmi di Programmazione Cos è un linguaggio Definizione 1 Un linguaggio è un insieme di parole e di metodi di combinazione delle parole usati e compresi da una comunità di persone. È una

Dettagli

Paradigma object-oriented

Paradigma object-oriented Paradigma object-oriented Dati & Comportamento Implementazione trasparente dei servizi Facile mantenimento Omogeneità nella gerarchia dati-funzioni Procedural approach OO approach Data hierarchy Replaced

Dettagli

ISO Revisions Whitepaper

ISO Revisions Whitepaper ISO Revisions ISO Revisions ISO Revisions Whitepaper Processi e procedure Verso il cambiamento Processo vs procedura Cosa vuol dire? Il concetto di gestione per processi è stato introdotto nella versione

Dettagli

Modelli di Processo. www.vincenzocalabro.it

Modelli di Processo. www.vincenzocalabro.it Modelli di Processo Il Modello del Processo Il modello del processo stabilisce i principi di base su cui si fonda lo sviluppo del software (e a cui è dovuto il successo o l insuccesso) Non esiste un unico

Dettagli