Ingegneria del software versione 1.0.5

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Ingegneria del software versione 1.0.5"

Transcript

1 Ingegneria del software versione Appunti 19 luglio 2006 Indice 1 Ciclo di vita del software Processo di sviluppo del software Modelli Agile Dierenze con altri modelli Quando usarlo Iterativo - Incrementale RAD Vantaggi Svantaggi Extreme Programming Planning Game Small Relesases Customers on-site Test First Refactoring Simplicity System Metaphor Pair Programming Collective Code Ownership Continous Integration Standards Overtime: 40 hour week JUnit RUP RUP best practices Ciclo di vita del Progetto Il modello a Cascata - WaterFall Il modello a Spirale Il modello a Release UXF 13 3 Metriche codice sorgente LOC eloc lloc DLOC SLOC Vantaggi Svantaggi UMM 15 5 XMI 15 6 COTS 16 7 SCM Goal FPA 17 9 COCOMO Basic COCOMO COCOMO II CORBA DFD Linguaggio Z Esempio - Denizione sistema Esempio - Add

2 2 Indice 14 Diagrammi UML Diagramma casi d'uso Diagramma delle classi Diagramma delle sequenze Diagramma delle collaborazioni Diagramma di stato Diagramma delle attività Diagramma dei componenti Diagramma di distribuzione dei componenti (deployment) 24 Bibliograa 25

3 1 Ciclo di vita del software 3 1 Ciclo di vita del software L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato nale è il prodotto stesso e tutta la documentazione a esso associato[1]. Esistono varie fasi: 1. Analisi: ovvero l'indagine preliminare sul contesto in cui il prodotto software deve inserirsi, sulle caratteristiche che deve esibire, ed eventualmente su costi e aspetti logistici della sua realizzazione; questa fase può essere scomposta in sottoattività quali: (a) analisi di fattibilità, (b) analisi e modellazione del dominio applicativo, (c) analisi dei requisiti. 2. Progetto: in cui si deniscono le linee essenziali della struttura del sistema da realizzare, in funzione dei requisiti evidenziati dall'analisi e dal documento nale da essa creato. Anche questa fase può essere scomposta in sottoattività: (a) progetto architetturale, (b) al progetto dettagliato. In questa fase verrà sviluppando un documento che permetterà di avere una denizione della struttura di massima (architettura di alto livello) e una denizione delle caratteristiche dei singoli componenti (moduli) 3. Implementazione 4. Testing (a) testing dei singoli moduli, (b) testing del sistema integrato, (c) test funzionali, (d) test di performance, (e) test di accettazione, (f) test d'installazione. 5. Manutenzione

4 4 1 Ciclo di vita del software 1.1 Processo di sviluppo del software L'UML (Unied Modelling Language), ad esempio, è un linguaggio di modellazione, utilizzato dai processi per realizzare, organizzare, documentare i prodotti realizzati dalle fasi di cui il processo si compone. Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla modica di un software, adottano necessariamente un certo approccio nel modo di relazionarsi con i propri clienti/utenti, nell'organizzare il proprio lavoro, nella scelta delle tecniche da utilizzare. Adottano un processo [1]. Il ciclo di sviluppo del software, nella maggior parte dei casi, è iterativo, e ogni iterazione produce una sua release. Elenchiamo di seguito le fasi principali che possono far parte di ogni singola iterazione: 1. Specica dei requisiti: ciò che viene richiesto dal committente 2. Analisi e Design dove per analisi si intende lo studio di cosa deve fare il sistema (punto di vista logico) e per design lo studio di come il sistema deve venire implementato (punto di vista tecnico). Negli ultimi anni, la distinzione tradizionale tra analisi e design è entrata in crisi. 3. Implementazione 4. Integrazione e test 1.2 Modelli Esistono molti modelli per lo sviluppo del software: iterativo ( ), Waterfall (a cascata) (1970), RAD ( ), spirale (1985), RUP (1998), Extreme Programming (XP) (1999). Agile (2001),

5 1 Ciclo di vita del software Agile Agile è una metodologia di sviluppo del software, un framework. Ci sono più tipi di agile software per sviluppare questo metodo, questi possono essere trovati nell'organizzazione no-prot The Agile Alliance. Questo metodo tenta di minimizzare i rischi dello sviluppo con piccole timeboxes, chiamate iterazioni, da una a quattro settimane. Ogni iterazione include delle fasi: planning, requirements analysis, design, coding, testing e documentation. Mentre una iterazione non garantisce il rilascio di un prodotto, l'agile software project, si propone di riuscire a rilasciare un nuovo software ad ogni iterazione. Alla ne di ogni iterazione, il tema ssa le priorità del progetto Dierenze con altri modelli <Agile> <Iterative> <Waterfall> <-*-**> Adaptive...Predictive Adaptive methods: si concentra sull'adattarsi velocemente ai cambiamenti. Predictive methods: si concentra sulla pianicazione dettagliata e futura del progetto Quando usarlo Più di 20 sviluppatori, distanza tra glil sviluppatori, mission- and life-critical eorts, command-and-control company cultures. 1.4 Iterativo - Incrementale Il modello iterativo, e incrementale, risponde alle debolezze dei modelli watefall. I due modelli di sviluppo iterativo più conosciuti sono RUP (Rational Unied Process), e DSDM (Dynamic Systems Development Method). Questo modello è una parte essenziale dell'xp (Extreme Programming) e tutti gli altri agile software frameworks.

6 6 1 Ciclo di vita del software 1.5 RAD (Rapid Application Development) RAD nato come risposta al metodologia non-agile, come il modello waterfall. Il problema con i precedenti modelli era quello che i requisiti cambiassero prima della conclusione del progetto, con il risultato di creare sistemi non utilizzabili Vantaggi Svantaggi accresce la velocità e qualità di sviluppo Questa velocità è dovuta all'uso di tool quali CASE 1 Per qualità nel modello RAD si intende il grado con il quale l'applicazione nita si riscontra con le aspettative del cliente, ed i costi di manutenzione bassi. Come svantaggi, riduce la scalabilità e le features. La scalabilità è ridotta perché questo modello parte da un prototipo e si evolve no alla applicazione nita; mentre riduce le features questo è dovuto al time boxing, le features vengono inserite tardi nelle versioni nali della release. 1.6 Extreme Programming L'extreme programming XP, è un modo di programmare che segue determinate regole, per cercare di ottimizzare il più possibile lavoro fatto dai programmatori [2]. Alcune di queste regole sono di seguito riportate: 1. Planning Game 2. Small Releases (Piccole release) 3. Customers on-site (Cliente sul posto) 4. Test First 5. Refactorig 6. Simplicity 7. System Metaphor 8. Pair Programming 9. Collective Code Ownership 10. Continous Integration 11. Code Standards 12. Overtime: 40 hour week L'obiettivo di questo tool è quello di catturare i requisiti e descriverli come codice nel modo più veloce possibile.

7 1 Ciclo di vita del software Planning Game Come Pianicare: Creare delle priorità (con il cliente) Stimare la dicoltà dei lavori (Lo sviluppatore) Lavorare in task paralleli, si è più veloci (Lo sviluppatore) Pianicare insieme i lavori ed i vari task all'inizio (Sviluppatore-Cliente) Small Relesases Signica piccole release frequenti, in genere prima dell'xp, si faceva il software per intero e poi si dava al committente validato; mentre ora si cerca di dare subito qualcosa al cliente, in modo che capisca subito se il software è corretto secondo le sue speciche; questo evita di fare lavoro inutile. In genere per il cliente viene sviluppato subito il 10% del programma in modo tale che sia veloce il riscontro in caso di problemi. Questa tecnica, evita la nascita e la morte poi di determinati software, con la perdita quindi di tempo e denaro, inoltre fa subito vedere se ci sono errori 2 o difetti 3 nei software prodotti Customers on-site Il committente deve essere tenuto sempre in stretto contatto con gli sviluppatori. In genere succede che dopo aver ottenuto l'ordine di progettare un software, il programmatore ed il cliente non si sentono quasi più no a software terminato: questo non deve succedere. Con l'xp, lo sviluppatore chiede subito al committente cosa sono le sue priorità, i moduli che devono essere sviluppati prima, e come devono essere sviluppati. Coinvolgere il cliente nei test per sapere se il software per lui è corretto, mostrare se il programma per lui è user-friendly Test First In genere i test vengono eseguiti dopo lo sviluppo della applicazione. Mentre in XP, il development è guidato dai test, questa può sembrare una perdita di 2 Per errore si intende una dimenticanza del programmatore Es.: un errore di battitura... 3 Per difetto si intende un problema nei risultati ottenuti dal software, risultati inattesi. (Altrimenti detto bug, Fault.)

8 8 1 Ciclo di vita del software tempo ma poi alla ne: si ha si, una perdita di tempo iniziale, ma si recupera sulla ne del progetto; mentre con l'approccio tradizionale si ha una velocità maggiore all'inizio per poi decelerare alla ne nella fase di Testing Refactoring Con questo termine, si intende modicare il codice, modicarne la struttura, il usso di controllo ma non il risultato. Ad esempio rinominare un metodo, aggiungere metodi a delle classi(ma senza cambiare il risultato del modulo). Il refactoring serve in generale per migliorare la qualità del codice. Divisione di un grande metodo in più parti Simplicity Cercare di tenere il progetto più semplice possibile System Metaphor Usare metafore vicine al dominio del committente. Se il cliente è un produttore di automobili, cercare di parlare dello sviluppo del software in termini di produzione di automobili, questo è una forma per cercare di capire nel miglior cosa deve fare il software prodotto Pair Programming Con il termine pair programming si intende, la programmazione in gruppo, per esempio in due, questa viene richiesta quando il compito è particolarmente dicile; su lavori critici si lavora insieme Collective Code Ownership Il codice scritto è di tutti gli sviluppatori; se si trova un errore nel programma la colpa è dell'intero team. Bisogna dire che essendo il codice di tutti, chi vuole può fare tutte le modiche, se secondo lui un modulo non è corretto lo può modicare, a patto che usi i CVS (Concurrent Version System,controllo di versione); inoltre al termine della modica il modulo modicato devo dare lo stesso risultato nei test del modulo vecchio; in altre parole non devo alterare i risultati che il modulo vecchio dava. Se non è così, allora in quel caso, la colpa è del programmatore che ha svolto la modica, il quale non si è preoccupato di vedere se i test erano ancora corretti; in conclusione, più libertà ma anche più responsabilità.

9 1 Ciclo di vita del software Continous Integration In genere il test di integrità viene fatto alla ne dello sviluppo dei singoli moduli con una frequenza molto alta di errori. L'XP dice che questo test deve essere fatto in modo più frequente proprio per evitare problemi di integrazione alla ne del progetto, molto più dicili da trovare e sistemare Standards Cercare di scrivere codice il più possibile in modo standard: es in java, i nomi delle classi iniziano con la lettera maiuscola, mentre per i nomi dei metodi si usano dei verbi Overtime: 40 hour week Per uno sviluppatore, le ore di straordinario, (overtime), sono permesse solo per una settimana, altrimenti c'è il rischio di commettere errori, mentre l'orario lavorativo normale non deve superare le 40 ore settimanali JUnit E' uno strumento che serve per eseguire Test di unità in Java. Utilizza la libreria Java riessione (per gestire le classi). Terminologia: Unit Test: una classe che testa un'altra classe Caso di Test: chiama un metodo con un input particolare e si osserva se il risultato è corretto Test Suite: una serie di casi di test Test Runner: serve per far partire i test Junit, introduce una nuova classe: nomeclassetest. Inoltre introduce due classi con nomi ssi: setup: inizializza la classe per eseguire i test teardown: libera la classe Junit utilizza le asserzioni per produrre il risultato dei test e vedere se sono corretti. Esempio in Java1:

10 10 1 Ciclo di vita del software 1 public class ES { 3 int mcd ( int x, int y) { 5... } 7 } 9 /* C r e o un ' a l t r a c l a s s e */ 11 public class ES TEST { 13 void testmcd () { 15 mcd (10,2) ; // Mi a s p e t t o c h e r e s t i t u i s c a 2 } 17 asserttrue ( mcd (10,2) ==2) ; asserttrue ( mcd (6,12) ==6) ; 19 } 21 /* * * * T i p i di A s s e r z i o n i * * * */ 23 static void asserttrue ( boolean test ) static void asserttrue ( String message, boolean test ) 25 static void assertfalse ( boolean test ) 27 static void assertfalse ( String message, boolean test ) 29 static void assertequals ( expected, actual ) static void assertequals ( String message, expected, actual ) Codice 1: Esempio in pseudolinguaggio Java Limiti e problemi del Testing con JUnit È una buona idea scrivere metodi che controllano lo stato di un oggetto Non è facile testare il codice delle GUI Con questo metodo si controlla l'output ma ha volte non è facile scrivere codice per questo controllo Non è facile testare svariati metodi che lavorano in parallelo per dare un risultato

11 1 Ciclo di vita del software 11 Sono comunque state proposte possibili soluzioni 1.7 RUP RUP (Rational Unied Process) è un software molto noto di sviluppo iterativo. RUP deve essere visto non come attraverso una singola prospettiva di lavoro, ma piuttosto un framework operativo adattabile alle esigenze RUP best practices 1. Sviluppo del software in modo iterativo, 2. gestione dei requisiti, 3. verica della qualità del codice, 4. CVS controllo dei cambiamenti apportati al software. RUP usa il modello iterativo per le seguenti ragioni: Il processo di integrazione viene fatto passo dopo passo durante lo sviluppo del software, limitandosi a farlo per pochi elementi alla volta, l'implementazione viene fatta per moduli, facilitando il riuso del software, se i requisiti cambiano è possibile adattarsi, l'architettura del software viene migliorata ad ogni release Ciclo di vita del Progetto È formato da quattro fasi vedi Figura 1 a Pagina 12: 1. Inception Phase (a) Stakeholder denizione, stima dei costi, tempi, (b) comprensione dei requisiti, (c) priorità costi/tempi, rischio, sviluppo del processo, (d) studio del prototipo architetturale che si è studiato, (e) spese attuali vs spese pianicate. 2. Elaboration Phase

12 12 1 Ciclo di vita del software (a) Generazione casi d'uso i casi d'uso completati all'80% (b) descrizione dell'architettura software, (c) piano di sviluppo per coprire tutto il progetto. 3. Construction Phase, 4. Transition Phase. Figura 1: Ciclo di vita del progetto Il modello a Cascata - WaterFall Figura 2: Modello WaterFall L'output di ogni fase è l'input della successiva; il principale limite di questo modello, è il fatto di non poter tornare indietro; se c'è un problema nel software che viene scoperto tardi bisogna ricominciare Il modello a Spirale In questo modello vedi Figura 3 a pagina 13, si crea un prototipo, attraverso le varie fasi: analisi dei requisiti, specica... e poi si fa l'analisi dei rischi

13 2 UXF 13 Figura 3: Modello a Spirale anche con il cliente per vedere se si può proseguire. Il principale vantaggio dei modelli a spirale e Release e che il software è in continua evoluzione [3] Il modello a Release In questo modello, si crea una prima release da sottoporre al cliente per ottenere un primo feedback; per poi correggerla o svilupparla ancora. Alla ne di tutte le release si ottiene il prodotto nale. 2 UXF UXF (UML exchange Format) è un modello di interscambio di formati per UML(Unied Modeling Language) basato su XML. Permette una alta inter operabilità; il team che sviluppa codice tramite questo modello, può riutilizzare e scambiare le informazioni tramite lo standard XML. XML è un sosticato sottoinsieme dell'sgml (Standard Generalized Markup Language: ISO 8879) i principali vantaggi sono: Indipendenza dal vendor (vender independence), Estensibilità, Possibilità di rappresentare delle informazioni complesse,

14 14 3 Metriche codice sorgente Leggibilità umana (Human readability), Interoperabilità tra i tools di sviluppo. 3 Metriche codice sorgente 3.1 LOC Line of code (LOC). LOC sono usate per stimare i tempi ed i costi. 3.2 eloc Eective line of code (ELOC), è la misura di tutte le line di codice che non sono commenti, spazi bianchi, e parentesi. Questa metrica rappresenta la quantità del lavoro. 3.3 lloc Logical lines of code (ILOC) rappresenta una metrica per gli statements; es.: for. Esempio: Source code line LOC eloc lloc Comment Blank if (x<10) // test range x x x { x // update y coordinate x x y = x + 1; x x x } x DLOC Developed line of code (DLOC). Include tutto il programma ed gli statement. Esiste anche il Kilo line of code (KLOC). 3.5 SLOC SLOC (Source lines of code) è una metrica usata per misurare il codice di un certo programma. SLOC viene usato per stimare lo sforzo richiesto per sviluppare un certo software.

15 5 XMI Vantaggi Automatizzare il conteggi delle linee di codice tramite tools Una metrica intuitiva: le righe di un software possono essere visionate Svantaggi 1. Non si può quanticare il costo, di un software contando le linee di codice, in altre parole contando solo la fase di codica la quale occupa solo il 33% - 35% di tutti il processo, 2. non ci permette di catturare questa diversità: un programmatore può scrivere poche righe di codice ma molto signicative, mentre un secondo programmatore ne scrive molte ma meno signicative e con più errori, 3. linguaggi dierenti, 4. GUI, tramite queste interfacce, il programmatore può fare copia ed incolla del codice già scritto in precedenza. 4 UMM UMM (UN/CEFACT's 4 Modeling Methodology), è una metodologia di modellazione la quale si sviluppa tramite UN/CEFACT. 5 XMI XMI (XML Metadata Interchange) è uno standard OMG per lo scambio di metadati tramite il linguaggio XML. Può essere usato per qualsiasi metadato purché questo possa essere espresso tramite MOF (Meta-Object Facility). L'uso più comune di XMI è per l'interscambio di modelli UML, i quali possono essere usati anche per altri linguaggi. XML - extensible Markup Language, W3C standard. UML - Unied Modeling Language, OMG modeling standard. 4 (The United Nations Centre for Trade facilitation and Electronic Business) UN/CE- FACT ha come scopo migliorare il business, e l'organizzazione amministrativa, sviluppo e transazioni economiche, scambio di prodotti e servizi; contribuisce allo sviluppo del commercio globale.

16 16 7 SCM MOF - Meta Object Facility, OMG DSL per la specica di metamodelli. MOF Mapping a XMI 6 COTS (Commercial o-the-shelf); COTS è un termine applicato nell'ambito sia dei prodotti software che hardware, il quale dice quando questo prodotto è pronto e disponibile alla vendita al pubblico. GOTS: government o-the-shelf, MOTS: modiable o-the-shelf, oppure military o-the-shelf. La motivazione che spinge ad utilizzare dei componenti COTS, è che riduce il tempo ed i costi di sviluppo del software; perché i componenti possono comprati e non progettati da zero. A volte tuttavia i costi di integrazione e la dipendenza da terze parti possono accrescere i costi. 7 SCM SCM (Software Conguration Management) è una parte del CM (Conguration Management). Risponde a queste domande: 1. Qualcuno fa qualcosa, come possiamo riprodurla? Spesso il problema si evolve e non è possibile riprodurlo in modo identico, ma servono dei cambiamenti incrementali. Tradizionalmente CM si è concentrato sul controllo e la creazione di prodotti semplici. Ai nostri giorni, la sda è quella fare il minor numero di incrementi; valutando la complessità del sistema che si sta sviluppando. 7.1 Goal Conguration Identication- Con quale codice noi lavoriamo? Conguration Control- Controllo delle release e eventuali cambiamenti. Status Accounting- Registrazione e report dei componenti.

17 8 FPA 17 Review- Assicurarsi della completezza dei vari componenti. Build Management- Gestione dei processi e dei tool utilizzati nel progetto FPA FPA (Function Point Analysis) è un metodo che misura la dimensione funzionale di un sistema informativo. Questo viene fatto osservando le transazioni funzionali e logiche del les rilevanti per gli utenti nel loro business [5]. Necessità di alcuni passi: 1. Identicare le funzioni del sistema che sono rilevanti per gli utenti 2. Determinare la complessità di ogni funzione 3. Contare le funzioni di tipo di dati per determinare il loro contributi al numero dei function point non pesati 4. Contare le funzioni di tipo transazionale per determinare il loro contributi al numero dei function point non pesati 5. Determinare il fattore di aggiustamento del valore 6. Calcolare il numero di function point pesati. Step 1 - FPA distingue tra cinque tipi di funzioni utente: 1. Internal Logical File (ILF) 2. External Interface File (EIF) 3. External Input (EI) 4. External Output (EO) 5. External Inquiry (EQ) Step 2 - FPA distingue tra tre tipi di complessità: 1. Low 2. Average 3. High

18 18 9 COCOMO 9 COCOMO COCOMO (COnstructive COst MOdel) è un modello progettato da Barry Boehm, per dare una stima del numero di uomini-mese che prenderanno parte allo sviluppo di un software. COCOMO consiste in una gerarchia di tre crescenti livelli di dettaglio: 1. Basic COCOMO: è statico, sforzo e costo dello sviluppo di un software come funzione della dimensione di un programma espressa nella sua stima delle linee di codice. 2. Intermediate COCOMO: sforzo come funzione della dimensione del programma e i cost drivers che includono subjective assessment of product, hardware, personale e project attributes. 3. Detailed COCOMO: incorpora tutte le caratteristiche della versione intermedia con un impatto dei cost driver ad ogni passo (analisi, progetto, codica... ), del processo di produzione del software. 9.1 Basic COCOMO Può essere applicato a tre tipologie di progetto: 1. Organic projects: sono relativamente piccoli, semplici progetti, 2. Semi-detached projects: sono una via di mezzo in termini di dimensione e complessità, 3. Embedded projects: sono progetti che devono essere sviluppati con hardware, software. L'equazione del basic COCOMO: E = a b (KLOC) b b D = c b (E) d b P = E/D dove E è lo sforzo (persone-mese), D è il tempo di sviluppo in un mese, KLOC è la stima del numero di line di codice per i progetto (espresse in migliaia), P è il numero di persone richieste. I coecienti a b, b b, c b, d b sono dati Tabella 1 a Pagina 19.

19 10 COCOMO II COCOMO II Software Project a b b b c b d b Organic Semi-detached Embedded Tabella 1: Coecienti Basic COCOMO Nel COCOMO II vengono apportate modiche al COCOMO I. Vengono deniti tre livelli di COCOMO, che corrispondono a tre classi di applicazioni e utilizzano informazioni reperibili in tre diversi momenti del ciclo di vita: 1. Application Composition: è il settore di chi utilizza primitive di alto livello per programmare (ad esempio GUI, spreadsheet) o si riferisce alla fase in cui viene generalmente eettuata una prototipazione per risolvere problemi ad alto rischio (interfacce utente, interazione software/sistema, prestazioni, maturità della tecnologia); vengono utilizzati gli Object Points, in quanto si ritiene che siano disponibili in maniera adabile in questa fase 2. Early Design: si passa alla fase di progetto, con l'esplorazione di alternative per le architetture; vengono usati i Function Points, il linguaggio e alcuni driver di costo in numero limitato, poiché in questa fase non è ancora noto molto a riguardo del progetto 3. Post-Architecture: si giunge alla fase di sviluppo tradizionale; si ottiene la stessa precisione di COCOMO 1; vengono usati LOC, Function Points e linguaggio con 17 cost drivers e 5 fattori di scala, che sostituiscono i fattori del modello precedente e i modelli Organic, Semidetachede Embedded Inoltre, il modello COCOMO II utilizza modelli non lineari per riuso e reingegnerizzazione permette il trattamento delle economie di scala apporta modiche ai moltiplicatori originari si avvale di un modello Bayesiano per i parametri del modello valutati da esperti

20 20 13 Linguaggio Z 11 CORBA L'OMG (Object Management Group), decise di promuovere il CORBA (Common Object Request Broker Architecture) una architettura distribuita orientata algi oggetti. Usando CORBA, un client può in modo trasparente (es.: senza conoscere l'implementazione del server in dettaglio) invocare un metodo su un server in due modi: in modo statico oppure tramite una invocazione dinamica. 12 DFD Un DFD (data ow diagram) è una rappresentazione graca di un usso di dati attraverso un sistema. Un diagramma di usso può essere utilizzato per visualizzare il data processing. 13 Linguaggio Z È un linguaggio per la specica formale, il quale usa la notazione matematica per descrivere in un modo preciso le proprietà e le informazioni che un sistema deve avere, senza conoscere in che modo queste proprietà vengono archiviate [7]; descrive che cosa il sistema deve fare senza sapere come [4]. Una importante caratteristica del linguaggio Z è quella di decomporre la specica in piccole parti chiamati schemas. Gli schema sono usati per descrivere aspetti statici e dinamici. Gli aspetti statici includono: lo stato che può essere occupato, le relazioni tra invarianti che sono mantenute quando un sistema si muove da uno stato all'altro. Gli aspetti dinamici includono: le operazioni possibili, le relazioni tra i loro input e output, i cambiamenti di stato.

21 13 Linguaggio Z Esempio - Denizione sistema Denire formalmente tramite il linguaggio Z un software che gestisce il nome e la data di compleanno di un database di persone. BirthdayBook known: P NAME birthday: NAME DATE known: dom Birthday known è il set dei record nomi con il compleanno birthday è la funzione la quale applicata ad un nome restituisce il compleanno L'ultima riga, è l'invariante in quanto è una relazione vera in ogni stato del sistema. Un possibile stato del sistema è dato da: known = { Primo, Michele, Claudia } birthday = { Primo 25Mar, Michele 20Dec, Claudia 20Dec }. L'invariate è rispettato in quanto il dominio dei birthday record è esattamente uguale a quello di known cioè Esempio - Add Aggiungiamo al sistema la possibilità di inserire nuovi dati. Lo schema è AddBirthday. AddBirthday BirthdayBook name?: NAME date?: DATE name? / known Birthday' =Birthday {name? date? } known è il set dei record nomi con il compleanno birthday è la funzione la quale applicata ad un nome restituisce il compleanno

22 22 14 Diagrammi UML 14 Diagrammi UML UML è un linguaggio di progettazione; UML è una evoluzione di modelli già esistenti, forti anità con ER (Entity - Relationship), FC (Flow Chart), modelli object oriented. Diagrammi UML: Livello logico: diagramma dei casi d'uso (use case) diagramma delle classi (class) diagramma di sequenza (sequence) diagramma di collaborazione (collaboration) diagramma di transizione di stato (state) diagramma delle attività (activity) Livello sico: diagramma dei componenti (component) diagramma di distribuzione dei componenti (deployment) 14.1 Diagramma casi d'uso Questi descrivono l'interazione tra attori e sistema, non la logica interna della funzione; sono infatti espressi in forma testuale, comprensibile anche per i non addetti ai lavori e possono essere deniti a livelli diversi (sistema o parti del sistema). Ragionare sui casi d'uso aiuta a scoprire i requisiti funzionali Diagramma delle classi Il diagramma delle classi, rappresenta le classi e gli oggetti che compongono il sistema, ed i relativi attributi ed operazioni [6, 1]. Specica, mediante le associazioni, i vincoli che legano tra loro le classi; può essere denito in fasi diverse (analisi, disegno di dettaglio) ed inoltre può rappresentare diverse tipologie di oggetti (oggetti business, oggetti di interfaccia,... ).

23 14 Diagrammi UML Diagramma delle sequenze Il diagramma delle sequenze, serve ad evidenziare il modo in cui uno scenario (uno specico percorso in un caso d'uso) viene risolto dalla collaborazione tra un insieme di oggetti; specica la sequenza dei messaggi che gli oggetti si scambiano inoltre può specicare nodi decisionali e iterazioni. Diagrammi di sequenza e diagrammi di collaborazione esprimono informazioni simili, ma le evidenziano in modo diverso Diagramma delle collaborazioni Il diagramma delle collaborazioni, specica gli oggetti che collaborano tra loro in un dato scenario, ed i messaggi che si indirizzano. La sequenza dei messaggi è meno evidente che nel diagramma di sequenza, mentre sono più evidenti i legami tra gli oggetti; può essere utilizzato in fasi diverse (analisi, disegno di dettaglio), e rappresentare diverse tipologie di oggetti Diagramma di stato Specica il ciclo di vita degli oggetti di una classe, denendo le regole che lo governano; quando un oggetto si trova in un certo stato può essere interessato da determinati eventi (e non da altri). Come risultato di un evento l'oggetto può passare ad un nuovo stato (transizione) Diagramma delle attività Serve a rappresentare sistemi di workow, oppure la logica interna di un processo (di qualunque livello, dai business process ai processi di dettaglio). Permette di rappresentare processi paralleli e la loro sincronizzazione; è un caso particolare di diagrammi di stato, in cui ogni stato è uno stato di attività Diagramma dei componenti Evidenzia l'organizzazione e le dipendenze esistenti tra componenti; i componenti sono moduli software eseguibili, dotati di identità e con un'interfaccia ben specicata, inoltre i componenti (come a livello logico le classi) possono essere raggruppati in package.

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

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

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

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

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

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

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

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

LEZIONE 9 - Linguaggi di Modellazione & UML

LEZIONE 9 - Linguaggi di Modellazione & UML Laboratorio di Ingegneria del Software a.a. 2013-2014 LEZIONE 9 - Linguaggi di Modellazione & UML Catia Trubiani Gran Sasso Science Institute (GSSI), L Aquila catia.trubiani@gssi.infn.it Cosa sono? 2 1

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

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

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

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

UML un linguaggio universale per la modellazione del software. Adriano Comai

UML un linguaggio universale per la modellazione del software. Adriano Comai UML un linguaggio universale per la modellazione del software Adriano Comai 2 Finalmente uno standard per l analisi e disegno OO? L'obiettivo è ambizioso. Lo Unified Modeling Language (UML) vuole essere,

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

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Object Oriented Analysis - OOA La fase di OOA definisce, secondo un approccio ad oggetti, COSA un prodotto software deve fare (mentre la fase di OOD definisce, sempre secondo un approccio ad oggetti, COME

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

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

Progetto di Informatica III

Progetto di Informatica III Progetto di Informatica III Sviluppo Agile (Agile Software Development) Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Metodologia agile Agile Manifesto Che cos è l agilità

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

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

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la

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

Progettazione orientata agli oggetti Introduzione a UML

Progettazione orientata agli oggetti Introduzione a UML Progettazione orientata agli oggetti Introduzione a UML Claudia Raibulet raibulet@disco.unimib.it Il processo di sviluppo software Rappresenta un insieme di attività per la specifica, progettazione, implementazione,

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

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

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

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

Automazione della gestione degli ordini d acquisto di una società di autonoleggio

Automazione della gestione degli ordini d acquisto di una società di autonoleggio Automazione della gestione degli ordini d acquisto di una società di autonoleggio Professore Gaetanino Paolone Studenti Paolo Del Gizzi Maurizio Di Stefano 1 INDICE INTRODUZIONE.pag.3 IL PIANO METODOLOGICO

Dettagli

Organizzazione della lezione. Extreme Programming (XP) Lezione 19 Extreme Programming e JUnit. JUnit. JUnit. Test-Driven Development

Organizzazione della lezione. Extreme Programming (XP) Lezione 19 Extreme Programming e JUnit. JUnit. JUnit. Test-Driven Development Organizzazione della lezione Lezione 19 Extreme Programming e JUnit Vittorio Scarano Corso di Programmazione Distribuita (2003-2004) Laurea di I livello in Informatica Università degli Studi di Salerno

Dettagli

Valutazione di strumenti per la modellazione UML

Valutazione di strumenti per la modellazione UML Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Ingegneria del Software Valutazione di strumenti per la modellazione UML Anno Accademico 2013/2014

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

Elenco dei manuali. Elenco dei manuali dell'utente di MEGA

Elenco dei manuali. Elenco dei manuali dell'utente di MEGA Elenco dei manuali Elenco dei manuali dell'utente di MEGA MEGA 2009 SP5 R7 1ª edizione (luglio 2012) Le informazioni contenute nel presente documento possono essere modificate senza preavviso e non costituiscono

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

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

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

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

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

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica Tecnologie dell informazione e della comunicazione per le aziende CAPITOLO 3: Progettazione e sviluppo

Dettagli

Business Modeling UML

Business Modeling UML Business Modeling UML versione 16 marzo 2009 Adriano Comai http://www.analisi-disegno.com Obiettivo di questa introduzione fornire alcuni elementi di base sul business modeling UML i temi esposti sono

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

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

Elenco dei manuali. Elenco dei manuali dell'utente di MEGA

Elenco dei manuali. Elenco dei manuali dell'utente di MEGA Elenco dei manuali Elenco dei manuali dell'utente di MEGA MEGA 2009 SP4 1ª edizione (giugno 2010) Le informazioni contenute nel presente documento possono essere modificate senza preavviso e non costituiscono

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

Studio di fattibilità (2) Identificazione ed analisi dei requisiti

Studio di fattibilità (2) Identificazione ed analisi dei requisiti Prime fasi nella produzione del software &RUVR GL,QJHJQHULD GHO 6RIWZDUH Capitolato d appalto o doc. formale di richiesta prodotto Incontri con il committente e/o interviste Esercitazione Studio del dominio

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

Calcolo della Dimensione Funzionale e della Produttività con il metodo IFPUG (CPM 4.3.1) L esperienza DDway con WebRatio

Calcolo della Dimensione Funzionale e della Produttività con il metodo IFPUG (CPM 4.3.1) L esperienza DDway con WebRatio Calcolo della Dimensione Funzionale e della Produttività con il metodo IFPUG (CPM 4.3.1) Questo documento contiene materiale estratto dal manuale IFPUG sulle Regole di Conteggio. È stato riprodotto in

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

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

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

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

Elenco dei manuali. Elenco dei manuali dell'utente di MEGA

Elenco dei manuali. Elenco dei manuali dell'utente di MEGA Elenco dei manuali Elenco dei manuali dell'utente di MEGA MEGA 2009 R6 1ª edizione (Novembre 2011) Le informazioni contenute nel presente documento possono essere modificate senza preavviso e non costituiscono

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

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

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

BPEL: Business Process Execution Language

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

Dettagli

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

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

Possibili domande del 2 compitino di Linguaggi di Programmazione per la Sicurezza

Possibili domande del 2 compitino di Linguaggi di Programmazione per la Sicurezza Possibili domande del 2 compitino di Linguaggi di Programmazione per la Sicurezza versione 1.2.5 Indice 1 Domande di Teoria 3 1.1 Extreme Programming...................... 3 1.1.1 Planning Game......................

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

Use Case Driven Object Modeling: ICONIX

Use Case Driven Object Modeling: ICONIX Use Case Driven Object Modeling: ICONIX Un esempio di specifica, analisi, progetto e sviluppo utilizzando ICONIX Ditta di Noleggio Dvd Un sistema per la gestione di una ditta di noleggio dvd che ha più

Dettagli

Sistemi Informativi I Function Point Analisys

Sistemi Informativi I Function Point Analisys 7. Stima dei costi. Nelle diverse fasi del progetto di sviluppo del software si possono individuare quattro principali voci di costo, corrispondenti alle fasi del ciclo posteriori allo studio di fattibilità:

Dettagli

Ingegneria del Software I Prova parziale del 27/4/2015 - ESERCIZI

Ingegneria del Software I Prova parziale del 27/4/2015 - ESERCIZI Cognome Nome Matricola Ingegneria del Software I Prova parziale del 27/4/2015 - ESERCIZI Durata: 1h 15' Esercizio 1 (6 pt.). Si supponga di dover implementare un sistema di lettura ed elaborazione automatica

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

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

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

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

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

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

Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite. Agile Group DIEE, Università di Cagliari www.agile.diee.unica.

Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite. Agile Group DIEE, Università di Cagliari www.agile.diee.unica. Metodologie Agili per lo sviluppo di applicazioni Internet Distribuite Agile Group DIEE, Università di Cagliari www.agile.diee.unica.it Agile Group Agile Group, gruppo di ricerca su Ingegneria del SW,

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

BiblioTech - Personal Digital Library

BiblioTech - Personal Digital Library Albana Gaba Alessandro Pegoraro Mirco Bocedi Fabio Giuseppe Strozzi Gruppo 8 Obiettivo Creare un software efficiente per la catalogazione di documenti digitali in categorie personalizzabili dall utente.

Dettagli

Sistemi elettronici per la sicurezza dei veicoli: presente e futuro. Il ruolo della norma ISO 26262 per la Sicurezza Funzionale

Sistemi elettronici per la sicurezza dei veicoli: presente e futuro. Il ruolo della norma ISO 26262 per la Sicurezza Funzionale La Sicurezza Funzionale del Software Prof. Riccardo Sisto Ordinario di Sistemi di Elaborazione delle Informazioni Dipartimento di Automatica e Informatica Sicurezza Funzionale del Vari Aspetti Sicurezza

Dettagli

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Prof. Andrea Borghesan & Dr.ssa Francesca Colgato venus.unive.it/borg borg@unive.it Ricevimento: mercoledì dalle 10.00 alle 11.00 Modalità

Dettagli

Linguaggi di Programmazione I Lezione 5

Linguaggi di Programmazione I Lezione 5 Linguaggi di Programmazione I Lezione 5 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 1 aprile 2008 Diagrammi UML 3 UML: richiami..........................................................

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

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

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

Progettazione del Software. Emiliano Casalicchio. Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti

Progettazione del Software. Emiliano Casalicchio. Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti Progettazione del Software L3.1 Emiliano Casalicchio Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti http://www.ce.uniroma2.it/courses/psw (Basato su materiale didattico

Dettagli

Ciclo di vita del software

Ciclo di vita del software Ciclo di vita del software Nel corso degli anni, nel passaggio dalla visione artigianale alla visione industriale del software, si è compreso che il processo andava formalizzato attraverso: un insieme

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

Sommario Unified Modeling Language Ing. Gianluca Di Tomassi www.ditomassi.it Modelli del processo SW Modello a cascata Sviluppo iterativo del SW Modello incrementale Modello a spirale Unified Modeling

Dettagli

Docenti: Patrizia Scandurra (referente princiaple) Angelo Gargantini. patrizia.scandurra@unibg.it

Docenti: Patrizia Scandurra (referente princiaple) Angelo Gargantini. patrizia.scandurra@unibg.it Progetto di Informatica III Introduzione al corso Patrizia Scandurra Università degli Studi di Bergamo a.a. 2009-10 Sommario Contatti Obiettivo Natura Argomenti Organizzazione Materiale didattico Modalità

Dettagli

simplesoad SOA/BPO ARCHITECT

simplesoad SOA/BPO ARCHITECT SIMPLE ENGINEERING simplesoad SOA/BPO ARCHITECT TRAINING CYCLE SHEET SIMPLESOAD_SA_COURSE_SHEET_IT_2007032701 SIMPLE ENGINEERING 2007 - ALL RIGHTS RESERVED. SIMPLE ENGINEERING IS AN INDEPENDENT EUROPEAN

Dettagli

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist www.roccatello.it

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist <eduard.roccatello@3dgis.it> www.roccatello.it Modellazione e progettazione con UML Eduard Roccatello 3D GIS Specialist www.roccatello.it Object Oriented Analysis and Design Consente di modellare un sistema attraverso l

Dettagli

Model Based Design per lo sviluppo e la verifica di moduli software in ambito Automotive

Model Based Design per lo sviluppo e la verifica di moduli software in ambito Automotive Model Based Design per lo sviluppo e la verifica di moduli software in ambito Automotive Automotive SPIN Italia - 4 Workshop on Automotive Software Roberto Sobrito, Software Engineer - FIAT Group Automobiles

Dettagli

Introduzione. La misurazione dei sistemi di Data Warehouse. Definizioni & Modelli. Sommario. Data Warehousing. Introduzione. Luca Santillo (CFPS)

Introduzione. La misurazione dei sistemi di Data Warehouse. Definizioni & Modelli. Sommario. Data Warehousing. Introduzione. Luca Santillo (CFPS) Introduzione La misurazione dei sistemi di Data Warehouse Luca Santillo (CFPS) AIPA, 17/5/01 In pratica I concetti generali, le definizioni e le regole di conteggio possono essere difficili da applicare

Dettagli

Il Processo Software

Il Processo Software Il Processo Software 29-03-2012 Prodotto Software Prodotto di qualità Tempi e costi determinati Processo Software Attività portanti Famiglia di compiti Attività ausiliari Quadro di riferimento Processo

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

UML - Unified Modeling Language

UML - Unified Modeling Language UML E CASI D USO UML - Unified Modeling Language Linguaggio stardardizzato per identificare e modellizzare le specifiche di un S.I. Coerente con il paradigma della programmazione ad oggetti Definito a

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

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

Certificazione di Proxy Applicativi e di applicazioni e servizi di cooperazione di Sistemi Informativi Locali

Certificazione di Proxy Applicativi e di applicazioni e servizi di cooperazione di Sistemi Informativi Locali Certificazione di Proxy Applicativi e di applicazioni e servizi di cooperazione di Sistemi Informativi Locali Ver. 1.0 11 Gennaio 2006 Riferimenti Documentazione CART - Regione Toscana [RT-PDK] Proxy Developer

Dettagli

tesi di laurea Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana candidato Pasquale Ludi Matr. 534\000438

tesi di laurea Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana candidato Pasquale Ludi Matr. 534\000438 tesi di laurea Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana candidato Pasquale Ludi Matr. 534\000438 Obbiettivi del progetto: Sviluppo di un applicazione Flex in AdobeFlashBuilder

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE Allegato 1.4 Cicli di vita del software Pagina 1 di 16 Indice 1 CICLI DI VITA... 3 1.1 Ciclo di Sviluppo... 3 1.2 Ciclo di Manutenzione... 5 2 LE FASI PROGETTUALI...

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

Progetto di Informatica III. Introduzione al corso

Progetto di Informatica III. Introduzione al corso Progetto di Informatica III Introduzione al corso Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Contatti Obiettivo Natura Argomenti Organizzazione Materiale didattico Modalità

Dettagli

Il metodo extreme Programming in sintesi

Il metodo extreme Programming in sintesi extreme Programming Approach Il metodo extreme Programming in sintesi Piergiuliano Bossi Coach Marina Morgagni Engagement Manager Quinary SpA Copyright 2001-2004 Quinary SpA Tutti i diritti sono riservati.

Dettagli