Roger S. Pressman, Principi di Ingegneria del software, a cura di M. Cerioli e G. Reggio, Copyright The McGraw-Hill Companies Srl

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Roger S. Pressman, Principi di Ingegneria del software, a cura di M. Cerioli e G. Reggio, Copyright 2008 - The McGraw-Hill Companies Srl"

Transcript

1 Soluzioni CAPITOLO 1 IL SOFTWARE E L INGEGNERIA DEL SOFTWARE 1.1 Chi avrebbe pensato che il software avrebbe indotto cambiamenti in: (1) modalità di corteggiamento (appuntamenti e conoscenze via Internet); (2) tipologia di comunicazione fra persone (telefoni cellulari); (3) metodologie belliche (armi cibernetiche); (4) diagnostica (TAC ed altre simili apparecchiature basate sui computer), e (5) acquisizione e fruizione di musica ed altre forme di intrattenimento (musica, DVD, itunes, etc.). 1.2 Questo è un buon problema per le discussioni in aula (se si trova il tempo). Invece di focalizzarsi su argomenti ben noti ed abusati (per quanto importanti e fondamentali), quali la privacy, la qualità della vita, ecc., potrebbe essere interessante discutere le paranoie tecnologiche e come il software possa contribuire ad esacerbarle o placarle. Un altra possibilità interessante è usare un articolo recente dalla Inside Risks Columns di Neumann (http://www.csl.sri.com/users/neumann/insiderisks.html) per focalizzare la discussione. Si potrebbero anche discutere nuove proposte di mercati economici e valute virtuali, nuovi modelli di intrattenimento interattivo, realtà virtuali, commercio elettronico ecc. 1.3 La realizzazione di un programma richiede tempi così lunghi perché a. Gli strumenti e l ambiente di sviluppo non sono disponibili online. b. Gli strumenti di sviluppo non funzionano come ci si aspettava. c. Il cliente pretende nuovi requisiti che a loro volta impongono di ripetere il design e lo sviluppo. d. Il prodotto dipende da regolamenti e leggi che cambiano inaspettatamente. e. Requisiti stringenti di compatibilità con sistemi preesistenti richiedono un maggiore sforzo di test, design ed implementazione rispetto a quanto previsto. f. Requisiti di operabilità su diverse piattaforme e sistemi operativi richiedono più tempo del previsto per essere soddisfatti. g. La gestione dei rischi del progetto software richiede più tempo del previsto. h. La necessità di impiegare nel progetto una tecnologia innovativa ancora in via di sviluppo allunga i tempi previsti. I costi di sviluppo sono così elevati perché a. Un livello inaccettabilmente basso di qualità richiede rielaborazioni (del design, dell implementazione e nuovo testing) inattese. b. Lo sviluppo di funzionalità sbagliate (rispetto alle aspettative del cliente) richiede di ripetere il design e/o l implementazione. c. Lo sviluppo di interfacce sbagliate (rispetto alle aspettative del cliente) richiede di ripetere il design e/o l implementazione.

2 d. Lo sviluppo di funzionalità ulteriori e non richieste prolunga lo schedule. Non è possibile individuare tutti gli errori prima di consegnare il prodotto perché a. Il prodotto dipende da regolamenti e leggi che cambiano inaspettatamente. b. Il prodotto dipende da standard tecnici, non ancora stabilizzati ufficialmente che cambiano inaspettatamente. c. Nuovo personale di sviluppo viene inserito a progetto già avanzato senza le dovute cautele. d. All interno del team di sviluppo si creano conflitti che producono scarsa comunicazione e quindi design di bassa qualità. e. Chi dovrebbe gestire il progetto lo sabota (anche non intenzionalmente) con schedule inefficiente e pianificazione inefficace. f. I componenti acquisiti sono di bassa qualità e richiedono ulteriori sforzi in design, extra testing e lavoro di integrazione, nonché in gestione della relazione col cliente. Occorre dedicare tanto tempo e impegno alla manutenzione dei programmi esistenti perché a. In molti casi i programmi sono indispensabili al buon funzionamento della ditta. b. Gli utenti sono abituati ad un prodotto e non vogliono cambiarlo con uno più moderno. c. Lo sforzo economico per sostituire il sistema non può essere sostenuto in un dato momento, mentre la manutenzione risulta più economica sul breve periodo. d. La tecnologia evolve rapidamente ed il sistema deve essere aggiornato per non diventare obsoleto. Continua a essere difficile misurare i progressi dello sviluppo del software perché a. Non sempre lo scopo del progetto è chiaro. b. Vi sono molti rischi gestionali coinvolti. c. Lo scope del progetto non è ben definito. d. Tutte le attività si ripetono iterativamente, cosicché non è banale capire quali sono i task da svolgere e in quale momento. e. Manca un buon meccanismo di monitoraggio del progetto. f. I membri del team si rifiutano di fornire lo stato di avanzamento. 1.4 La definizione di software presentata nel Paragrafo 1.2 si applica anche ai siti Web. Vi sono tuttavia delle differenze sottili fra un sito Web ed un software convenzionale. Una delle più notevoli è che i contenuti presentati da un sito Web vengono considerati parte dell applicazione Web, mentre usualmente i dati elaborati dal software convenzionale si considerano distinti dalle funzioni offerte dal software.

3 1.5 Molte applicazioni moderne cambiano più volte prima di essere presentate al cliente ed anche dopo che la prima versione è entrata in uso. Alcune tecniche per costruire software in modo da evitare che si deteriori con le modifiche (o quanto meno limitarne i peggioramenti) potrebbero essere: Assicurarsi che la progettazione del software garantisca che i cambi in una parte del programma non abbiano effetti indesiderati in altre parti. Assicurarsi che il software sia progettato in modo da evitare dipendenze esterne da altri sistemi o apparecchiature con alta probabilità di cambiamenti futuri. Assicurarsi di archiviare i test case ed i relativi risultati in modo che sia agevole riusarli nella fase dei test del software modificato. Assicurarsi di avere capito a fondo le esigenze del cliente. 1.6 Lo stesso approccio all ingegneria del software può essere applicato ad ognuna delle categorie, ma deve essere adattato per soddisfare i requisiti specifici di ciascuna di esse. 1.7 Ciascuna di queste nuove sfide indubitabilmente seguirà la Legge delle Conseguenze inattese ed avrà effetti (sui commerciali,gli ingegneri software e gli utenti finali) che non si possono prevedere ora. Tuttavia gli ingegneri software possono prepararsi adottando un processo sufficientemente agile ed adattabile da poter gestire drammatici cambiamenti nella tecnologia o nelle regole business che inevitabilmente si presenteranno nella prossima decade. A.I. Dopo quasi 40 anni di false partenze, l intelligenza artificiale (AI, per Artificial Intelligence) sta finalmente diventando un successo tecnologico ed industriale. Attualmente si possiede un arsenale di tecniche per la costruzione di programmi che controllano processi manifatturieri, diagnosticano fault nei computer e malattie negli esseri umani,progettano computer, giocano a scacchi e così via. In associazione con il riconoscimento vocale e l incredibile capacità di calcolo delle macchine moderne, molto probabilmente le applicazioni di AI diventeranno sempre più umane col passare degli anni. Vi saranno, inevitabilmente, conseguenze inattese. 1.8 La legge della conservazione della stabilità organizzativa: il tasso medio di attività effettiva globale è invariante durante tutto il ciclo di vita del software. 1.9 La legge della conservazione della familiarità: durante l evoluzione del sistema tutte le figure coinvolte, utenti, ingegneri software, sviluppatori, devono avere una conoscenza completa dei suoi contenuti e behavior per ottenere risultati soddisfacenti. Un eccessivo aumento del tasso di crescita può diminuire tale conoscenza (padronanza); pertanto il tasso medio di crescita rimane invariante durante l evoluzione del sistema La legge della riduzione della qualità: la qualità dei sistemi tende a diminuire a meno che non vengano mantenuti mediante apposite procedure per adattarli ai cambiamenti dell ambiente. Questo concetto è analogo al deterioramento discusso nei problemi Gli esempi della vita reale fra cui scegliere sono letteralmente dozzine. Ad

4 esempio, gli errori software che hanno causato il fallimento delle principali reti telefoniche, i fallimenti nell industria aeronautica che hanno contribuito alle catastrofi aeree, i virus informatici (ad esempio Michelangelo, Slammer, o Code red) che hanno causato ingenti danni economici e attacchi ad importanti siti di e- commerce Le due categorie più ampie raccolgono i rischi economici e quelli che mettono in pericolo il benessere e la salute degli individui. Potrebbe essere una buona idea scegliere (dalle fonti suggerite) 5 rischi e discuterli in aula. È meglio selezionare alcuni rischi seri ed altri più ridicoli e divertenti.

5 Soluzioni CAPITOLO 2 PANORAMICA SUL PROCESSO 2.1 a. I progettisti dovrebbero chiedere agli utenti: o Che cosa vuoi che faccia questo prodotto? o Quali sono gli output fondamentali di questo software? o Quali funzionalità e caratteristiche desideri? o Quali output, funzioni e caratteristiche probabilmente cambieranno nei prossimi 6 mesi, un anno? o Ci sono domande che avrei dovuto porre e non ho fatto? o Come farai a decidere se il nostro prodotto corrisponde alle tue aspettative? b. Gli utenti dovrebbero chiedere ai progettisti: o Ho chiarito sufficientemente le mie esigenze? o Abbiamo gli strumenti e le persone con le competenze necessarie allo sviluppo? o I requisiti sono ben definiti? Servono ulteriori requisiti? o Le caratteristiche e le funzionalità del prodotto si possono sviluppare nel tempo previsto? o Avete parlato con altre classi di utenti? c. Gli utenti dovrebbero chiedersi sul prodotto software che viene realizzato: o Ho chiesto più di quello che mi serve realmente? o Ho fissato delle deadline non realistiche? o Ho incertezze riguardanti qualche funzionalità o caratteristica? o Per alcune funzionalità o caratteristiche, sarebbe utile un prototipo? o Mi sono impegnato a lavorare con i progettisti sul lungo periodo? d. I progettisti dovrebbero chiedersi sul prodotto software che stanno realizzando e i processi che verranno utilizzati per costruirlo: o Ho capito lo scope e lo scopo del software? o Ho capito i problemi del design ed i vincoli a cui è soggetto? o Quali strumenti si useranno? o Ho capito la tecnologia e l area applicativa di riferimento del software da produrre? o Abbiamo stabilito criteri di qualità per poter giudicare il nostro

6 lavoro? 2.2 Si potrebbe suggerire agli studenti di utilizzare i riferimenti segnalati nella sezione Ulteriori letture e fonti di informazioni del Capitolo La fase di supporto si applica differentemente per il software embedded. Nella maggioranza dei casi, il software embedded viene specificato e sviluppato, ma una volta inserito nell apparato che lo ospita, non è probabile che debba cambiare finché non ha luogo un aggiornamento del prodotto che lo contiene. 2.4 Le attività ombrello sono presenti durante tutto il processo di sviluppo software, ma non necessariamente sono applicate uniformemente. Ad esempio, l analisi dei rischi richiede molta attenzione durante la pianificazione del progetto e viene poi mantenuta aggiornata durante le successive attività strutturali, ma non viene applicata in ugual misura in ciascuna di esse. Al contrario, la gestione della qualità si applica pressa poco in uguale misura durante tutto il processo. 2.5 La struttura di un processo si applica a tutti i processi; pertanto le stesse attività strutturali si applicano a tutti i processi, indipendentemente dalla loro dimensione o complessità. La struttura di un processo richiede anzitutto una stretta comunicazione con il cliente per raccogliere i requisiti; questa attività stabilisce un piano per il lavoro di ingegneria del software che seguirà. La struttura di un processo prevede inoltre la creazione di modelli che faciliteranno la comprensione fra lo sviluppatore ed il cliente nello sforzo di capire e progettare i requisiti; in seguito richiede una fase di costruzione (generazione del codice e testing). Infine fornisce feedback basato sulla valutazione. 2.6 Un Task Set per l attività di Comunicazione: un Task Set dovrebbe definire in concreto i singoli task da svolgere per raggiungere gli obiettivi di un attività di ingegneria del software. Nel caso dell attività di comunicazione essi sono: 1. Stendere una lista degli stakeholder del progetto 2. Invitarli tutti ad un incontro informale 3. Chiedere a ciascuno di loro di produrre una lista delle funzionalità e caratteristiche desiderate 4. Discutere i requisiti e compilare una lista finale 5. Attribuire a ciascun requisito una priorità e annotarsi le aree in cui gli stakeholder presentano incertezze Questi task potrebbero essere espansi nel caso di progetti software complessi, ad esempio prendendo in considerazione i seguenti: Condurre una serie di incontri per le specifiche, stilare una lista preliminare delle funzionalità e delle caratteristiche basate sugli input degli stakeholder. Produrre una lista riveduta dei requisiti degli stakeholder usando tecniche di QFD (Quality Function Deployment) per assegnare priorità ai requisiti. Annotarsi vincoli e restrizioni sul sistema.

7 Discutere i metodi di validazione del sistema. 2.7 Il CMMI rappresenta un meta-modello di processo in due sensi diversi il modello continuo e quello a fasi. I vantaggi del CMMI: omnicomprensivo, copre sostanzialmente ogni aspetto del processo, ben organizzato, molto adottato. I contro: pesante, eccessivo per molti tipi di processo, l agilità è discutibile. Si dovrebbe sempre adottare lo spirito del CMMI, ma ciascun processo deve poi essere adattato per adeguarsi alle necessità del team di sviluppo e per raggiungere un elevato livello di qualità nel prodotto finale. Si dovrebbero applicare i requisiti del CMMI a tutti i modelli di processo, ma carenze su uno specifico criterio non necessariamente significano che il processo sia scadente. Può darsi che il CMMI sia corretto in situazioni in cui una cultura organizzativa possa essere migliorata verso un modello di processo standard e la direzione si impegni fortemente per ottenere tale risultato. Tuttavia, il CMMI può essere troppo pesante per essere totalmente assimilato da un organizzazione. Quindi lo stesso CMMI che è adatto ad un organizzazione può non esserlo ad un altra. 2.8 Il lettore interessato può scaricare il testo completo del CMMI da 2.9 Nome pattern: Scopo: Tipo: Comunicazione Stabilire una collaborazione con i clienti allo scopo di definire lo scope del progetto, i requisiti business e altri vincoli del progetto Pattern a stadi Contesto iniziale: (1) Sono stati identificati gli stakeholder appropriati ed essi sono disponibili a partecipare all attività di comunicazione (2) Gli stakeholder concordano sul fatto che esiste un problema e che un sistema software potrebbe offrirne una soluzione. Problema: Bisogna raccogliere dagli stakeholder i requisiti ed organizzarli in modo che gli ingegneri software possano usarli facilmente. Tutti gli stakeholder devono collaborare alla definizione dei requisiti ed all identificazione delle aree in cui i requisiti non sono chiari. Soluzione: Ciascuno stakeholder deve sviluppare una descrizione delle funzionalità, caratteristiche, informazioni e behavior che saranno proprie del software. A questo scopo si terrà un incontro strutturato e facilitato. Per maggiori dettagli consultare le sezioni 9.3, 9.4 e 9.5. Contesto risultante: Al termine di un corretto svolgimento di questo pattern, saranno state raccolte ed opportunamente documentate le informazioni di base sufficienti allo sviluppo di un modello analitico. Si sono sviluppati use case (esempi d uso), come pure descrizioni di base delle

8 Pattern correlati: Applicazioni note/esempi: funzionalità e del behavior del sistema, dei dati che saranno manipolati e/o prodotti. Condurre un incontro; raccolta dei requisiti; sviluppo di use case; costruzione di una minispecifica; negoziazione dei requisiti; prioritarizzazione. L attività di comunicazione è obbligatoria all inizio di ogni progetto software; è inoltre raccomandata durante tutto lo sviluppo del progetto ed è nuovamente obbligatoria durante l attività di deployment La valutazione del processo esamina il processo software adottato da un organizzazione per determinare se è efficace per ottenere gli scopi dell ingegneria del software. La valutazione caratterizza la pratica corrente di una unità organizzativa in termini della capacità dei processi selezionati. Lo standard SPICE (ISO/IEC15504) definisce un insieme di requisiti per la valutazione del processo software. Per effettuare la valutazione, SPICE specifica un modello di riferimento che esamina lo scopo e gli obiettivi misurabili del processo (la dimensione del processo ) e l insieme di attributi del processo che dovrebbero essere presenti (la dimensione di capacità ) Il processo PSP (Personal Software Process) enfatizza la misura personale sia del prodotto realizzato sia della sua qualità. Il modello del processo PSP definisce cinque attività strutturali: pianificazione, progettazione ad alto livello, revisione del progetto ad alto livello, sviluppo e post-mortem. Inoltre, PSP rende ciascuno sviluppatore responsabile per la pianificazione del progetto (ad esempio stime e pianificazioni temporali) e gli attribuisce il controllo della qualità di tutti i prodotti software sviluppati Gli script definiscono specifiche attività del processo (lancio del progetto, progettazione, implementazione, integrazione e testing, post-mortem) e altre funzioni di lavoro più dettagliate (pianificazione dello sviluppo, sviluppo dei requisiti, gestione della configurazione software e testing delle unità) che fanno parte del processo del team. Gli script possono essere utili quando il team ha bisogno di indicazioni per pianificare e tenere traccia del proprio lavoro, stabilire gli obiettivi e definire gli effettivi task set per le attività tecniche. Per team con maggiore esperienza, d altra parte, possono impedire gli adattamenti in corso d opera che sono spesso necessari in ambienti agili.

9 Soluzioni CAPITOLO 3 MODELLI DI PROCESSO PRESCRITTIVI 3.1 La vera domanda che un testo dovrebbe affrontare è: Come si può sviluppare un processo che riesca a gestire i molti e caotici attributi del moderno sviluppo software? Gli autori suggeriscono processi che siano focalizzati su flessibilità e possibilità di estensione piuttosto che su qualità elevata e ammettono che questo approccio fa paura. Senza dubbio alcuno! In effetti, noi crediamo che sia una sicura ricetta per un disastro. Ad eccezione di alcuni sistemi operativi per PC di grande diffusione (che lasceremo nell anonimato) la qualità sembra un ragionevole indicatore di un software di successo. Un programma, per quanto estensibile e flessibile, non potrà avere successo se fallisce regolarmente ed è imprevedibile. Si dovrebbe considerare che molto si è scritto sul software abbastanza buono. Tutto questo va bene fintanto che non i perde l enfasi sulla parola buono. 3.2 Il modello a cascata è appropriato per progetti con le seguenti caratteristiche: (1) si ha una profonda comprensione del problema (i requisiti sono ben definiti); (2) la data di consegna è realistica; (3) è improbabile che vengano richieste modifiche sostanziali dei requisiti durante lo sviluppo. Esempi specifici potrebbero essere: (1) una modifica di un programma esistente che sia stata studiata a fondo; (2) un implementazione immediata di un algoritmo numerico o di una regola business per quanto complessa; (3) un miglioramento soggetto a vincoli di codice esistente. 3.3 Le applicazioni software sufficientemente facili da sviluppare a prototipi riguardano quasi sempre interazioni uomo-macchina e/o molta computer graphics. Altre applicazioni che si possono talvolta adattare a questo tipo di sviluppo sono certe classi di algoritmi matematici, sottoinsiemi di sistemi gestiti mediante comandi e altre applicazioni in cui i risultati possano essere esaminati facilmente senza interazioni real-time. Applicazioni più difficili da realizzare mediante uno sviluppo a prototipi comprendono le funzioni di controllo e di controllo dei processi, molte classi di funzioni real-time e di software embedded. 3.4 Se si pianifica di far evolvere il prototipo fino ad ottenere un applicazione da consegnare al cliente, bisogna applicare fin dall inizio regole di progettazione e procedure di SQA (controllo qualità) molto più rigorose. Inoltre, il prototipo deve essere progettato tenendo bene a mente la necessità di evoluzione e deve essere implementato usando un ambiente di programmazione compatibile con quello per lo sviluppo del sistema. Inizialmente il prototipo serve come meccanismo per l identificazione dei requisiti. Una volta completato, il prototipo diventa lo scheletro (l impalcatura) per le estensioni che lo trasformeranno in un sistema finale, realistico ed accettabile dal cliente. 3.5 RAD assume che un progetto possa essere suddiviso in moduli in maniera tale per cui ciascuna funzionalità principale possa essere consegnata in una finestra

10 temporale di giorni. Benché questa condizione si verifichi spesso, vi sono situazioni in cui i tempi di realizzazione sono inevitabilmente più lunghi. Inoltre RAD assume che siano disponibili risorse umane sufficienti per portare avanti in parallelo i vari incrementi. Non sempre questa assunzione è realistica. 3.6 Tutti i progetti software che hanno funzionalità significative da consegnare in tempi molto (troppo) ristretti sono buoni candidati per un approccio incrementale. L idea è consegnare le funzionalità in incrementi successivi. Ad esempio, un prodotto software sofisticato che può essere rilasciato sul mercato con solo parte delle funzionalità operative e l annuncio di imminenti nuove versioni migliorate. Un esempio concreto è un elaboratore di testi sviluppato secondo il paradigma incrementale, che potrebbe fornire nel primo incremento solo funzionalità base di gestione dei file, di formattazione e produzione di documenti, nel secondo incremento funzionalità più sofisticate per formattazione e produzione di documenti, nel terzo incremento verifiche lessicali e grammaticali e nel quarto incremento capacità di impaginazione avanzate. Il processo di sviluppo di ciascun incremento potrebbe valersi del paradigma a prototipi. Lo sviluppo incrementale è particolarmente utile quando il personale è insufficiente per completare l implementazione entro i termini richiesti dal business e stabili come deadline del progetto. 3.7 Mentre si procede lungo il flusso del processo a spirale, il prodotto procede verso uno stato sempre più completo ed il livello di astrazione a cui silavora si riduce (ovvero, il lavoro specifico dell implementazione accelera man mano che ci si allontana dall origine). 3.8 I modelli di processo possono essere combinati. Ciascun modello suggerisce un flusso di processo lievemente differente, ma tutti prevedono lo stesso insieme di attività strutturali: comunicazione, pianificazione, modellazione,costruzione e deployment. Ad esempio il modello sequenziale lineare (a cascata) può essere utile in situazioni in cui i requisiti sono fissati ed il lavoro procede linearmente fino al completamento del sistema. In alcuni casi, in cui lo sviluppatore non è sicuro dell efficienza di un algoritmo, dell adattabilità di un sistema operativo, e della forma che dovrebbe assumere l interazione uomo-macchina, un modello a prototipi può essere la scelta migliore. In altri casi, un approccio incrementale può avere senso ed il flusso delmodelloa spirale può essere efficiente. Speciali modelli di processo assumono molte caratteristiche di uno o più modelli tradizionali. 3.9 In parole povere, il modello di processo concorrente assume che differenti parti di uno stesso processo si troveranno in diversi stati di completezza e che, perciò, differenti attività di ingegneria del software saranno eseguite concorrentemente. La sfida è gestire la concorrenza e riuscire a stabilire lo stato complessivo del progetto Il vantaggio dello sviluppo di software in cui la qualità è abbastanza buona è che il prodotto software sarà consegnato in tempo, tuttavia questo tipo di sviluppo può indurre a consegnare software di bassa qualità, che richiederà tempo per migliorarne la qualità. Quando si privilegia la velocità sulla qualità, il processo può portare a molti difetti il software può richiedere più testing, e

11 rielaborazioni del design e dell implementazione Questo problema può servire ad introdurre l importanza del riuso. Per risolverlo, lo studente dovrebbe indagare librerie di componenti esistenti per determinare quali componenti riusabili siano disponibili. Ad esempio esistono molti componenti riusabili per interfacce utenti. Pertanto qualsiasi applicazione con una parte preponderante, o quanto meno rilevante di interfaccia utente sarà un candidato per il CBSE È possibile usare tecniche matematiche per provare la correttezza di componenti software e perfino di interi programmi. Tuttavia, si tratta di un processo che richiede molto tempo se il programma è complesso. Non è possibile provare la correttezza di programmi non banali mediante testing esaustivo Le proprietà richieste dai clienti o le aree di interesse tecnico spesso hanno impatto sull intera architettura. Quando queste proprietà, dette concern, hanno impatto su molteplici funzioni, caratteristiche, informazioni del sistema, si dicono crosscutting concerns. Lo sviluppo aspect-oriented di software, spesso detto anche programmazione aspect-oriented (AOP), è un paradigma di ingegneria del software relativamente innovativo che fornisce un processo ed un approccio metodologico alla definizione, design e costruzione di aspetti meccanismi al di fuori di subroutine ed ereditarietà per localizzare l espressione di un crosscutting concern UML fornisce la tecnologia necessaria a supportare la pratica dell ingegneria del software object-oriented (e tradizionale), ma non fornisce l infrastruttura di processo per guidare i team di progetto nella loro applicazione della tecnologia. Il Processo Unificato è un infrastruttura per l ingegneria del software che usa UML. Attualmente il processo unificato ed UML si usano in progetti di ogni tipo. Tuttavia, non sono affatto la stessa cosa. UML è una notazione ed un linguaggio di modellazione (si veda il Capitolo 7). UP è un modello di processo in cui UML può essere applicato come parte delle attività di ingegneria del software Un flusso di lavoro di ingegneria del software è distribuito su tutte le fasi del processo unificato. Nel contesto di UP, un flusso di lavoro è analogo ad un task set. In altre parole, un flusso di lavoro identifica i task necessari per completare un importante azione di ingegneria del software e i prodotti risultanti del corretto completamento dei task stessi. In UP si ha un flusso di lavoro per ogni progetto software, mentre le fasi di UP non si verificano necessariamente in sequenza, ma piuttosto approssimativamente concorrenti. È molto probabile che in UP si svolgano contemporaneamente le fasi di costruzione, transizione e produzione, mentre il lavoro è già iniziato sull incremento software successivo.

12 Soluzioni CAPITOLO 4 SVILUPPO AGILE 4.1 Ciascuno dei quattro valori è lodevole, ma ciascuno può mettere nei guai il team di sviluppo. Ad esempio, gli individui e le loro interazioni sono molto importanti, ma un progetto complesso può fallire a causa di una cattiva scelta tecnologica (ad esempio, i processi e gli strumenti sono di bassa qualità). La disponibilità di software funzionante è senza dubbio lo scopo ultimo, ma provate a dirlo a chi dovrà mantenere l applicazione da lì a tre anni quando tutti i membri del team di sviluppo originale se ne sano andati. La collaborazione col cliente è certo lodevole, ma la negoziazione aiuta ad evitare aspettative non realistiche e, nei casi peggiori, dispute legali. La pronta risposta ai cambiamenti è fondamentale, ma un ambiente di progetto caotico (senza pianificazione) in molti casi porta direttamente al fallimento. 4.2 L agilità può essere applicata a qualsiasi processo software. Tuttavia, per farlo, è essenziale che il processo sia progettato in modo da permettere al team di sviluppo di adattare i task e la loro distribuzione, di pianificare in modo compatibile con la fluidità di un approccio agile allo sviluppo, di eliminare tutti i prodotti intermedi tranne quelli veramente indispensabili e di ridurli all essenziale, di enfatizzare una strategia di consegna incrementale che permetta al cliente di avere software funzionante con la massima rapidità compatibile col tipo di prodotto e l ambiente di sviluppo. 4.3 Il team di sviluppo software gestisce i cambiamenti focalizzandosi su incrementi ben definiti (cioè lo scope del singolo incremento è ben definito) e rimandando ciascun cambiamento all incremento successivo. Tutti i modelli di processo agili sono iterativi/incrementali. Ad esempio, ASD usa un processo iterativo che incorpora la pianificazione di un ciclo adattivo, metodi di raccolta dei requisiti relativamente rigorosi, ed un ciclo di sviluppo iterativo che prevede focus group di clienti e revisioni tecniche formali come meccanismi per ricevere feedback in tempo utile durante le sviluppo. Il metodo DSDM definisce tre diversi cicli iterativi functional model iteration (iterazione sul modello funzionale), design and build iteration (iterazione di progettazione e realizzazione) e implementation (implementazione) preceduti da altre due attività feasability study (studio di fattibilità) e business study (studio del business). 4.4 Si possono applicare le attività strutturali generiche ai processi agili trattati in questo capitolo. La tabella dovrebbe elencare tutti i processi agili nella prima riga e tutte le attività generiche (comunicazione, pianificazione, modellazione, costruzione e deployment) nella prima colonna. Si analizzi la descrizione di ciascun processo agile per individuare il nome dell analoga attività del processo, ad esempio: Comunicazione XP: pianificazione - user stories

13 Pianificazione XP: Modellazione XP: Costruzione XP: Deployment XP: pianificazione assunzione d impegno per uno specifico incremento software design, spike solution, refactoring pair programming, unit testing acceptance testing, customer tests 4.5 Un ulteriore principio di agilità che aiuterebbe un team di ingegneria del software a divenire ancora più manovrabile potrebbe essere Un team dovrebbe conoscere di chi sono le competenze che più si addicono ad un particolare progetto e far assegnare questi professionisti al loro progetto, in modo da rendere più efficace lo sviluppo del software. Un altro potrebbe essere: La comunicazione è la chiave, utente e sviluppatore dovrebbero comunicare regolarmente anche se geograficamente separati. 4.6 Uno dei principi di agilità presentati nel Paragrafo 4.1 è Si devono accettare con entusiasmo le richieste di cambiamento, anche se intervengono in una fase avanzata dello sviluppo. I processi agili accettano il cambiamento in quanto essenziale per garantire un vantaggio competitivo al cliente. Ciascun processo presentato in questo capitolo segue questo principio. 4.7 I requisiti cambiano così tanto perché è difficile prevedere in anticipo quali requisiti resteranno validi e quali cambieranno. È altrettanto difficile prevedere come cambieranno le priorità dei clienti durante lo sviluppo del progetto. Spesso è difficile per le persone esprimere le loro necessità relative al software prima di aver visto un prototipo funzionante, perché solo allora realizzano di aver dimenticato di prendere in considerazione un aspetto importante. 4.8 Considerando i sette tratti presentati nel Paragrafo 4.2.2, sulla base dell opinione personale i tratti potrebbero essere ordinati dal più al meno importante come segue: Competenza. In un contesto di sviluppo agile (come in ogni altro settore dell ingegneria del software convenzionale), la competenza comprende talento innato, specifiche abilità nella realizzazione del software e una conoscenza generale del processo scelto dal team. Obiettivi comuni. Sebbene i membri di un team agile possano svolgere compiti differenti e portare nel progetto abilità differenti, tutti dovrebbero concentrarsi su un unico obiettivo. Collaborazione. L ingegneria del software (indipendentemente dal processo utilizzato) prevede la valutazione, l analisi e l uso di informazioni che vengono comunicate al team di sviluppo software. Reciproca fiducia e rispetto. Il team coeso dimostra la fiducia e il rispetto necessari a renderli così ben amalgamati che l intero è maggiore della somma delle parti. Auto-organizzazione. Il team dovrebbe avere il controllo sulla propria struttura interna. Capacità di prendere decisioni. Ogni buon team di sviluppo software (compresi i

14 team agili) deve avere la libertà di controllare il proprio destino. Capacità di soluzione creativa dei problemi. I manager dell attività di sviluppo software devono riconoscere il fatto che il team agile continuerà ad avere a che fare con forme di ambiguità ed a subire assestamenti per i costanti cambi. È importante realizzare che non c è una sola risposta corretta. Ciascuno può percepire differentemente l importanza dei singoli tratti. 4.9 La vicinanza fisica è importante. Una domanda può avere una risposta immediata, un problema può essere discusso senza ritardi, la negoziazione avviene naturalmente attraverso la comunicazione personale senza bisogno di pianificarla (e quindi in modo più efficace). Non c è modo migliore di lavorare! Tuttavia la vicinanza fisica non sempre è possibile. La maggior parte dei modelli di processi agili consiglia la comunicazione di persona. Attualmente, questo può essere ottenuto con video-conferenze di costo contenuto, gruppi di discussioni basati sul Web e altri metodi elettronici. Queste soluzioni non sono altrettanto efficaci della vicinanza fisica, ma possono in gran parte portare ad analoghi risultati Esempio: Ciascun sito Web che intendo poter visitare nuovamente in futuro può essere memorizzato nei Preferiti. Dovrei essere in grado di associare dei nomi agli URL dei siti e raggrupparli secondo categorie di mia definizione, memorizzare un preferito sotto una particolare categoria, ordinare le URL nel modo che preferisco, ed accedere all elenco dei Preferiti in qualsiasi momento dal menu del browser. Dovrei essere in grado di visualizzare tutti i miei Preferiti nella finestra del mio browser raggruppati secondo le categorie di appartenenza, selezionarne uno col mouse in modo che il browser individui l URL corrispondente e visualizzi il contenuto del sito Se nell ambito della progettazione di una user story viene rilevato un problema progettuale difficoltoso, XP prevede l immediata creazione di un prototipo operativo per tale porzione del progetto. Questo prototipo progettuale, chiamato spike solution (un esperimento mirato, letteralmente soluzione puntuale ), viene poi implementato e valutato. Lo scopo è quello di ridurre i rischi all avvio dell implementazione e convalidare le stime originarie per la user story contenente il problema progettuale La programmazione XP incoraggia anche il refactoring una tecnica realizzativa che è anche una tecnica progettuale. Il refactoring è il processo di modifica di un sistema software in modo da non alterare il comportamento esterno del codice ma da migliorarne la struttura interna. Una nozione fondamentale in XP è il fatto che la progettazione non si conclude con l inizio della programmazione. A causa del refactoring, la progettazione si ripresenta costantemente a mano a mano che viene costruito il sistema. Un concetto chiave durante l attività di programmazione è il pair programming. XP prevede l impiego di due persone che collaborano alla stessa workstation per sviluppare il codice corrispondente ad una user story. Questo fornisce un meccanismo di soluzione in tempo reale dei problemi (due teste ragionano meglio di una) e una garanzia di qualità.

15 4.13 Esempio di Pattern di processo per Scrum Nome pattern: Scopo: Tipo: Contesto iniziale: Problema: Soluzione: Contesto risultante: Pattern correlati: Applicazioni note/esempi: Scrum riunione quotidiana rispondere alle tre domande di base mediante un breve incontro da svolgersi quotidianamente pattern a compito (1) il progetto deve essere stato avviato ed il backlog già definito; (2) si sta svolgendo uno sprint; (3) Tutti i membri del team Scrum si sono accordati per incontrarsi quotidianamente in un luogo specifico per la riunione Scrum; (4) e stato individuato un leader per il team. Spesso è difficile per i membri del team rendersi conto dello stato del progetto e di a che punto siano gli altri membri del team con il loro lavoro. Quando si organizzano riunioni per mettere tutti a parte dello stato di avanzamento molto spesso si perde troppo tempo senza conseguire lo scopo. Si veda la descrizione della riunione Scrum in Sezione Alla conclusione della riunione ciascun partecipante ha risposto alle domande: (1) Che cosa hai fatto dall ultima riunione Scrum? (2) Che ostacoli stai affrontando? (3) Che cosa pensi di ottenere prima della prossima riunione? preparazione del backlog, gestione di uno sprint Le riunioni Scrum vengono effettuate durante ciascun progetto Scrum e sono un importante elemento di comunicazione Come altri metodi agili, l approccio Crystal enfatizza collaborazione e comunicazione fra le persone che hanno vari interessi sul progetto software. Il metodo è anche adattabile a varie culture del team e può prevedere approcci sia informali sia relativamente formali all ingegneria del software ed è per questo definita una famiglia di metodi agili. In realtà la famiglia Crystal è un insieme di esempi di processi agili che si sono dimostrati effettivi per differenti tipi di progetto. Il suo scopo è permettere al team agile di selezionare il membro della famiglia Crystal che è più appropriato per il loro tipo di progetto e di ambiente Il template per la definizione di una feature in FDD è il seguente: <azione> il/lo/la/i/gli/le <risultato> <mediante per di a> un(o/a) <oggetto> Esempi: specificare l URL di un sito Web visualizzare il contenuto di un sito Web compilare una form Web visualizzare tutte le URL dei Preferiti

16 4.16 Un sito web da esaminare per i principi AM potrebbe essere

17 Soluzioni CAPITOLO 5 PANORAMICA SUGLI ASPETTI PRATICI DELL INGEGNERIA DEL SOFTWARE 5.1 David Hooker ha proposto sette principi base che si concentrano sulla pratica dell ingegneria del software nel suo complesso: 1. Il primo principio: il senso dell esistenza Un sistema software esiste per un unico motivo, dare valore ad i suoi utenti. 2. Il secondo principio: il principio di semplicità KISS (Keep It Simple, Stupid!) La progettazione di software non può essere un processo vago. In ogni attività di progettazione vi sono molti fattori da considerare. Tutta la progettazione deve essere improntata alla massima semplicità ma senza esagerare. 3. Il terzo principio: concentrarsi sulla visione Una visione chiara è essenziale per il successo di un progetto software. Senza una visione, un progetto finirà quasi certamente per avere di se stesso una visione schizofrenica. 4. Il quarto principio: ciò che si sta producendo verrà consumato da altri Raramente un sistema software a livello industriale viene costruito e utilizzato nel vuoto. In un modo o nell altro, vi sarà qualcuno che lo utilizza, lo gestisce, lo documenta o in qualche modo dipende dalla capacità di comprendere il sistema. 5. Il quinto principio: essere aperti verso il futuro Un sistema di lunga durata avrà un valore superiore. 6. Il sesto principio: pianificare per il riuso Il riuso consente di risparmiare tempo e fatica. 7. Il settimo principio: riflettere! Una riflessione chiara e completa prima di ogni azione produce quasi sempre risultati migliori. Riassumendo in un'unica frase: Bisogna assicurarsi che il sistema che si vuole costruire costituisca un valore aggiunto per i suoi utenti. Mentre lo si costruisce, bisogna mantenere tanto il sistema stesso quanto il processo usato per costruirlo quanto più semplici è possibile, mantenendo allo stesso tempo chiaro in mente lo scopo finale. Non bisogna dimenticare che il sistema sarà mantenuto da altri né che deve essere possibile cambiarlo, man mano che le esigenze a cui risponde si modificano col passare del tempo. Durante la costruzione, bisogna cercare di creare astrazioni che possano essere riusate in altri progetti, ma soprattutto non bisogna mai spegnere il cervello quando si lavora. 5.2 Gli elementi tecnici fondamentali consigliabili per l ingegneria del software comprendono: (1) la necessità di testare approfonditamente il software allo scopo di trovare errori; (2) la necessità di utilizzare strumenti automatici per facilitare lo sviluppo e migliorare la comprensione tecnica; (3) la necessità di misurare il prodotto ed utilizzare le misure effettuate per migliorare la qualità

18 tecnica. 5.3 Gli elementi gestionali fondamentali consigliabili per l ingegneria del software comprendono: (1) comunicazione continua ed efficace con tutti gli stakeholder; (2) adozione di un punto di vista agile, indipendentemente dal modello di processo adottato; (3) un insieme di pratiche gestionali e tecniche che permettano al team di definire il proprio percorso mentre avanza verso il suo scopo ultimo. 5.4 Un importante principio della comunicazione stabilisce che occorre prepararsi prima di comunicare. I principi ed i concetti di comunicazione con il cliente si concentrano sulla necessità di diminuire il rumore e migliorare la banda al progredire della conversazione fra sviluppatori e clienti. Entrambe le parti devono collaborare per ottenere una migliore comunicazione. A questo scopo, l ingegnere software deve: (1) studiare il dominio business a cui si rivolge il sistema di costruire, (2) comprendere i giocatori (cioè gli stakeholder) che specificheranno i requisiti; (3) sviluppare una strategia ben definita per la raccolta dei requisiti; (4) comprendere il fine di ciascuno stakeholder; (5) capire che la negoziazione è inevitabile. 5.5 La facilitazione dell attività di comunicazione è essenziale durante la raccolta dei requisiti. Ogni riunione di comunicazione dovrebbe avere un leader (un facilitatore) allo scopo di (1) mantenere la conversazione concentrata in una direzione produttiva, (2) mediare i conflitti che si dovessero verificare, (3) garantire l aderenza agli altri principi. Semplici linee guida sono: Comprendere il dominio business. Capire chi sono gli stakeholder e quali fini hanno. Stabilire un meccanismo ben definito per la raccolta dei requisiti. Creare un metodo per la memorizzazione dei requisiti. Stabilire un modo per assegnare priorità ai bisogni. 5.6 Il punto di vista agile sulla comunicazione e sulla collaborazione col cliente enfatizza la necessità per tutti gli stakeholder di lavorare (sempre) come una squadra, di condividere il luogo di lavoro e di riconoscere che il cambiamento è una parte ineluttabile del processo. Tuttavia, i punti fondamentali della filosofia agile della comunicazione si possono applicare ad ogni pratica di ingegneria del software e come tutte le altre pratiche anche comunicazione e collaborazione sono iterative. Ogni iterazione diffonde nuove importanti informazioni e migliora la comprensione complessiva del software da produrre. 5.7 È necessario procedere oltre perché la comunicazione, come tutte le altre attività di ingegneria del software, richiede tempo. Piuttosto che iterare interminabilmente, le persone coinvolte dovrebbero riconoscere che molti punti richiedono discussione e che procedere oltre è talvolta il modo migliore di conseguire una vera agilità di comunicazione. Inoltre, il progetto deve progredire incessantemente. Non bisogna permettere che bloccarsi su un punto lo faccia diventare un collo di bottiglia del processo. 5.8 La negoziazione per l attività di comunicazione funziona al meglio se entrambe le parti vincono. Semplici linee guida comprendono:

19 Stabilire che siamo tutti nella stessa squadra e abbiamo tutti lo stesso scopo per produrre un sistema che effettivamente soddisfi le esigenze dell utente. Cercare sempre di trovare un punto di accordo quello su cui si è tutti concordi. Riconoscere che entrambi i lati dovranno cedere qualcosa al compromesso. Non trascendere mai su aspetti personali, né recriminare mantenere la discussione sul software. 5.9 Il termine granularità fa riferimento al livello di dettaglio scelto durante lo sviluppo del piano di progetto. Un piano a granularità fine fornisce dettagli significativi per un task di lavoro pianificato su un intervallo temporale relativamente breve (cosicché verifiche e controlli siano frequenti). Un piano a granularità grossolana fornisce task di lavoro pianificati su intervalli temporali più lunghi. In generale, la granularità diventa progressivamente meno fine quanto più ci si allontana dal momento attuale verso il futuro nel piano di sviluppo del progetto Il modello del design per il software è l equivalente dei progetti di un architetto per una casa. In principio rappresenta la visione d insieme delle cose da costruire (ad esempio un modellino tridimensionale della casa) e lentamente viene raffinato per fornire la guida necessaria alla costruzione di ciascun aspetto (ad esempio il piano della rete idraulica). Analogamente, il modello del design fornisce un insieme di diverse viste del sistema ed è quindi necessario per tutti i progetti meno che banali I modelli analitici definiscono i requisiti del cliente, rappresentando il software in tre diversi domini: il dominio delle informazioni, il dominio delle funzioni ed il dominio del behaviour. I modelli del design rappresentano invece le caratteristiche del software che aiutano gli sviluppatori a produrlo efficacemente: l architettura, l interfaccia utente ed i dettagli a livello dei componenti Un principio ulteriore rispetto a quelli affermati sulla programmazione nel Paragrafo 5.6 potrebbe essere Il codice dovrebbe auto-documentarsi, cioè il codice dovrebbe essere scritto in modo così chiaro da risultare auto-esplicativo Un test di successo è quello che consente di scoprire un errore ancora ignoto Non si può concordare con la frase proposta. Ciascun incremento si basa sui precedenti e nessuno vorrebbe costruire su fondamenta di bassa qualità. Inoltre, se i primi incrementi hanno una qualità insoddisfacente, clienti ed utenti si preoccupano (perdono fiducia nella competenza del team); si potrebbe sviluppare un inutile tensione e la comunicazione successiva ne potrebbe risultare compromessa Il feedback è importante per il team software perché fornisce le informazioni da usare per correggere gli errori di modellazione, cambiare i fraintendimenti e aggiungere funzionalità o caratteristiche che erano state involontariamente

20 omesse.

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

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

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

Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi

Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Rischi 1 Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Un ingegnere del software viene coinvolto direttamente nel processo di identificazione delle aree potenziali

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

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

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

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

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

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

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

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

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

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

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

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

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

Dettagli

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

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

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software 5 Gestione dei progetti software. Dopo aver completato lo studio del ciclo di vita del software, in questa parte vengono discussi gli aspetti gestionali della produzione del software. Vengono esaminate

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

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA Il project management nella scuola superiore di Antonio e Martina Dell Anna 2 PARTE I PROCESSI AZIENDALI E PROGETTI UDA 3 I PRINCIPI DEL PROJECT MANAGEMENT

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

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

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: 1.0. www.analisi-disegno.com. Pag. 1

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: 1.0. www.analisi-disegno.com. Pag. 1 Scrum Caratteristiche, Punti di forza, Limiti versione del tutorial: 1.0 Pag. 1 Scrum è uno dei processi agili (www.agilealliance.com) il termine è derivato dal Rugby, dove viene chiamato Scrum il pacchetto

Dettagli

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

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Test Giulio Destri Ing. del Software: Test - 1 Scopo del modulo Definire

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

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

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

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 1. Introduzione...3 1.2. Application vs Tool... 3 2. Componenti logiche di un modello... 6 3. Ontologie e Semantic

Dettagli

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES è una metodologia per implementare rapidamente sistemi informativi aziendali complessi,

Dettagli

Metodi e Modelli per le Decisioni

Metodi e Modelli per le Decisioni Metodi e Modelli per le Decisioni Corso di Laurea in Informatica e Corso di Laurea in Matematica Roberto Cordone DI - Università degli Studi di Milano Lezioni: Giovedì 13.30-15.30 Venerdì 15.30-17.30 Ricevimento:

Dettagli

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Fondamenti di Informatica Linguaggi di Programmazione Michele Tomaiuolo Linguaggi macchina I

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

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

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36

10. Design Patterns. Andrea Polini. Ingegneria del Software Corso di Laurea in Informatica. (Ingegneria del Software) 10. Design Patterns 1 / 36 10. Design Patterns Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 10. Design Patterns 1 / 36 Problemi Ci focalizziamo nelle problematiche riguardanti la

Dettagli

Gestione del gruppo di lavoro: motivazione e coaching

Gestione del gruppo di lavoro: motivazione e coaching Gestione del gruppo di lavoro: motivazione e coaching Il team Un gruppo di persone che: condividono uno scopo, hanno un obiettivo in comune collaborano, moltiplicando le loro risorse condividono i vantaggi

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

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it Programmazione II Lezione 4 Daniele Sgandurra daniele.sgandurra@iit.cnr.it 30/09/2011 1/46 Programmazione II Lezione 4 30/09/2011 Sommario 1 Esercitazione 2 Panoramica della Programmazione Ad Oggetti 3

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

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

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

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

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

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 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

Le FAQ della simulazione

Le FAQ della simulazione Le FAQ della simulazione L obiettivo di queste FAQ è fornire ai progettisti di corsi di formazione, a docenti, agli utenti di corsi di formazione e a coloro che sono addetti allo sviluppo delle risorse

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

Ottimizzare Agile per la. agility made possible. massima innovazione

Ottimizzare Agile per la. agility made possible. massima innovazione Ottimizzare Agile per la agility made possible massima innovazione Agile accelera l'offerta di innovazione Lo scenario aziendale attuale così esigente e in rapida evoluzione ha enormemente amplificato

Dettagli

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che Prefazione In questo volume completiamo l esplorazione del linguaggio Java che abbiamo iniziato in Java Fondamenti di programmazione. I due testi fanno parte di un percorso didattico unitario, come testimoniano

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini ANALISI E PROGETTAZIONE OBJECT ORIENTED Lorenzo Saladini 1. Introduzione In questo capitolo vengono presentati alcuni degli elementi necessari al corretto sviluppo di sistemi informatici secondo una metodologia

Dettagli

Il modello RAD 1. Rapid Application Development punta a un ciclo di sviluppo molto breve

Il modello RAD 1. Rapid Application Development punta a un ciclo di sviluppo molto breve Il modello RAD 1 Rapid Application Development punta a un ciclo di sviluppo molto breve adattamento del modello a cascata in cui l obiettivo di uno sviluppo rapido è raggiunto grazie a strategie costruttive

Dettagli

Strategie didattiche per gli studenti dislessici in tutti i gradi di scuola tratto dal sito AID -Sezione di Roma

Strategie didattiche per gli studenti dislessici in tutti i gradi di scuola tratto dal sito AID -Sezione di Roma Strategie didattiche per gli studenti dislessici in tutti i gradi di scuola tratto dal sito AID -Sezione di Roma (testo tradotto da Accommodating students with dyslexia in all classroom settings International

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

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1 Università degli Studi di Salerno GPS: Gestione Progetti Software Project Proposal Versione 1.1 Data 27/03/2009 Project Manager: D Amato Angelo 0521000698 Partecipanti: Nome Andrea Cesaro Giuseppe Russo

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

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

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

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale tesi di laurea inventario comunale Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo Ing. Luigi Pontillo candidato Michele Vitelli Matr. 534 2170 Redazione dell Inventario

Dettagli

Criteri fondamentali per un sistema CRM

Criteri fondamentali per un sistema CRM Criteri fondamentali per un sistema CRM Definizione di C.R.M. - Customer Relationship Management Le aziende di maggiore successo dimostrano abilità nell identificare, capire e soddisfare i bisogni e le

Dettagli

KNOWLEDGE MANAGEMENT. Knowledge Management. Knowledge: : cos è. Dispense del corso di Gestione della Conoscenza d Impresa

KNOWLEDGE MANAGEMENT. Knowledge Management. Knowledge: : cos è. Dispense del corso di Gestione della Conoscenza d Impresa KNOWLEDGE MANAGEMENT Pasquale Lops Giovanni Semeraro Dispense del corso di Gestione della Conoscenza d Impresa 1/23 Knowledge Management La complessità crescente della società, l esubero di informazioni

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Coordinamento e comunicazione

Coordinamento e comunicazione Team Agili I membri del team devono fidarsi gli uni degli altri. Le competenze dei membri del team deve essere appropriata al problema. Evitare tutte le tossine che creano problemi Il team si organizza

Dettagli

Semplifica la gestione di una forza lavoro globale

Semplifica la gestione di una forza lavoro globale Semplifica la gestione di una forza lavoro globale Cezanne HR è un azienda internazionale, che gestisce clienti in tutto il mondo. Per questo sappiamo quanto possa essere complicato gestire le Risorse

Dettagli

GUIDA DI APPROFONDIMENTO LA SCELTA DEI FORNITORI A CURA DEL BIC SARDEGNA SPA

GUIDA DI APPROFONDIMENTO LA SCELTA DEI FORNITORI A CURA DEL BIC SARDEGNA SPA GUIDA DI APPROFONDIMENTO LA SCELTA DEI FORNITORI A CURA DEL BIC SARDEGNA SPA 1 SOMMARIO PREMESSA... 3 LE CONSIDERAZIONI STRATEGICHE DA FARE SUI FORNITORI... 4 CONCENTRARSI SUGLI OBIETTIVI... 4 RIDURRE

Dettagli

Prepararsi al Cambiamento Passaggio alla ISO 9001:2015

Prepararsi al Cambiamento Passaggio alla ISO 9001:2015 Prepararsi al Cambiamento Passaggio alla ISO 9001:2015 Come è ormai noto a quanti operano nel campo della qualità, è stata pubblicata la nuova revisione della ISO 9001. Le Norme ISO toccano numerosi ambiti

Dettagli

Fase di offerta. Realizzazione del progetto

Fase di offerta. Realizzazione del progetto Linee guida per un buon progetto Commissione dell informazione e dei Sistemi di Automazione Civili e Industriali CONTENUTI A) Studio di fattibilità B) Progetto di massima della soluzione C) Definizione

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 del Software

Ingegneria del Software Appunti di Ingegneria del Software Rosario Terranova v 1.0.4 http://rosarioterranova.com/ Sommario Introduzione... 4 Cos è l ingegneria del software... 4 Caratteristiche del software e differenze dagli

Dettagli

Informazioni Tecniche su TachyCAD

Informazioni Tecniche su TachyCAD Informazioni Tecniche su TachyCAD Le seguenti pagine danno una panoramica dettagliata dei possibili utilizzi di TachyCAD. Per ulteriori domande o commenti, contattateci direttamente. Kubit Italia Topotek

Dettagli

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it Processi di Business e Sistemi di Gestione di Workflow: concetti di base Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Le aziende devono modificare la loro organizzazione per cogliere le nuove

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

GUIDA VELOCE PER TRAINER

GUIDA VELOCE PER TRAINER GUIDA VELOCE ~ 6 ~ GUIDA VELOCE PER TRAINER Perché usare il toolkit di EMPLOY? In quanto membro del personale docente, consulente di carriera, addetto al servizio per l impiego o chiunque interessato ad

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

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

Linguaggi di Programmazione I Lezione 6

Linguaggi di Programmazione I Lezione 6 Linguaggi di Programmazione I Lezione 6 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 8 aprile 2008 Analisi di oggetti e classi 3 Introduzione............................................................

Dettagli

Ingegneria del Software. Introduzione ai pattern

Ingegneria del Software. Introduzione ai pattern Ingegneria del Software Introduzione ai pattern 1 Definizione di pattern [dal [dal vocabolario vocabolario Garzanti] Garzanti] Alcuni esempi: Pattern architetturale Pattern di circuito stampato Pattern

Dettagli

Programmazione. Prima lezione sugli oggetti: agenda

Programmazione. Prima lezione sugli oggetti: agenda Programmazione A.A. 2002-03 I Programmazione Orientata agli Oggetti (1): Principi generali ( Lezione XXV ) Prof. Giovanni Gallo Dr. Gianluca Cincotti Dipartimento di Matematica e Informatica Università

Dettagli

La semplicità di formare i lavoratori in somministrazione

La semplicità di formare i lavoratori in somministrazione La semplicità di formare i lavoratori in somministrazione un catalogo di offerta formativa multimediale MiFORMOeLAVORO è il progetto, lanciato da Adversus in collaborazione con Skilla, che ha l obiettivo

Dettagli

Ref: 2013-1-ES1-LEO05-66260

Ref: 2013-1-ES1-LEO05-66260 Ref: 2013-1-ES1-LEO05-66260 Buone pratiche nell uso di ambienti di apprendimento collaborativo quali strumenti per favorire la creatività ed identificazione di modelli di successo nel settore metalmeccanico

Dettagli

FOCUS SUI CITTADINI: UNA PARTECIPAZIONE AMPIA PER POLITICHE E SERVIZI MIGLIORI. Abstract

FOCUS SUI CITTADINI: UNA PARTECIPAZIONE AMPIA PER POLITICHE E SERVIZI MIGLIORI. Abstract www.qualitapa.gov.it FOCUS SUI CITTADINI: UNA PARTECIPAZIONE AMPIA PER POLITICHE E SERVIZI MIGLIORI Abstract L importanza di un processo di policy making trasparente e inclusivo è largamente condivisa

Dettagli

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti Alessio Bechini - Corso di - Il paradigma OO e le relative metodologie di progettazione Metodologie OO Programmazione orientata agli oggetti La programmazione ad oggetti (OOP) è un paradigma di programmazione

Dettagli

Corso di Laurea Triennale in Ingegneria Informatica. Corso di Ingegneria del software A. A. 2004-2005. Marina Mongiello

Corso di Laurea Triennale in Ingegneria Informatica. Corso di Ingegneria del software A. A. 2004-2005. Marina Mongiello Corso di Laurea Triennale in Ingegneria Informatica Corso di Ingegneria del A. A. 2004-2005 1 La progettazione È applicata indipendentemente dal modello di processo utilizzato. Parte dal punto in cui sono

Dettagli

Tecniche di DM: Link analysis e Association discovery

Tecniche di DM: Link analysis e Association discovery Tecniche di DM: Link analysis e Association discovery Vincenzo Antonio Manganaro vincenzomang@virgilio.it, www.statistica.too.it Indice 1 Architettura di un generico algoritmo di DM. 2 2 Regole di associazione:

Dettagli

Cosa significa che il SW è non lineare? Piccoli cambiamenti nel codice portano a grandi cambiamenti di comportamento

Cosa significa che il SW è non lineare? Piccoli cambiamenti nel codice portano a grandi cambiamenti di comportamento Cosa significa che il SW è non lineare? Piccoli cambiamenti nel codice portano a grandi cambiamenti di comportamento Cosa s'intende per Information Hiding? Impedire l'accesso a dettagli implementativi

Dettagli

ARIES. Architettura per l implementazione rapida dei sistemi aziendali

ARIES. Architettura per l implementazione rapida dei sistemi aziendali ARIES Architettura per l implementazione rapida dei sistemi aziendali P r e s e n ta z i o n e d e l l a m e t o d o l o g i a a r i e s ARIES è una metodologia che consente di implementare rapidamente

Dettagli

Traccia per Focus Group

Traccia per Focus Group Traccia per Focus Group Introduzione per i docenti Gentili docenti, un ringraziamento anticipato, e non di circostanza, per la vostra collaborazione all'attività di approfondimento della sperimentazione.

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A. 2008-2009. Class Discovery E.

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A. 2008-2009. Class Discovery E. Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Class Discovery E. TINELLI Contenuti Classi di analisi: definizione ed esempi Tecniche per la definizione

Dettagli

Indice. Il bilancio delle competenze. Il curriculum vitae Il mio progetto. Banche dati

Indice. Il bilancio delle competenze. Il curriculum vitae Il mio progetto. Banche dati Indice Il bilancio delle competenze Competenze Il curriculum vitae Il mio progetto Stabilire mete Banche dati Il bilancio delle competenze La consapevolezza di sé comporta la conoscenza dei propri stati

Dettagli

Fasi di creazione di un programma

Fasi di creazione di un programma Fasi di creazione di un programma 1. Studio Preliminare 2. Analisi del Sistema 6. Manutenzione e Test 3. Progettazione 5. Implementazione 4. Sviluppo 41 Sviluppo di programmi Per la costruzione di un programma

Dettagli

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali

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

Dettagli

APPRENDIMENTO ed EDUCAZIONE

APPRENDIMENTO ed EDUCAZIONE EDUCARE è COSTRUZIONE DI SENSO gruppo classe = gruppo di lavoro? ma si differenzia da questo, che è regolato da ruoli, norme e obiettivi precisi e condivisi, perché non è la norma nella sua interezza che

Dettagli

Ingegneria del Software - Il Ciclo Lungo

Ingegneria del Software - Il Ciclo Lungo Ingegneria del Software - Il Ciclo Lungo Alessandro Martinelli alessandro.martinelli@unipv.it 10 Marzo 2014 Il Ciclo Lungo Il Versioning e la Condivisione di Codice Organizzazione dei Pacchetti La Modellazione

Dettagli

QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO

QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO QUATTRO BUONE PRATICHE PER L IMPLEMENTAZIONE DI UNA TECNOLOGIA PER LA DIDATTICA DI SUCCESSO Report globale e suggerimenti Gennaio 2013 Autore: Filigree Consulting Promosso da: SMART Technologies Executive

Dettagli

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

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

Dettagli

!"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&) !"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9

!#$%&&'()#*%+%+!#$',,'()#*%+ -)%*&'&'+'$.)+-$$%&&) !#$%&&'(%)'*+%,#-%#.'%&'#/0)-+#12+3,)4+56#7+#.')8'9 !"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&)!"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9 Slide 1 Paradigmi di Programmazione! Un linguaggio supporta uno stile di programmazione se

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