FAQ di Ingegneria del Software (versione 07 Febbraio 2012)

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "FAQ di Ingegneria del Software (versione 07 Febbraio 2012)"

Transcript

1 FAQ di Ingegneria del Software (versione 07 Febbraio 2012) Lo scopo di queste FAQ è quello di fornire un aiuto per un'autovalutazione in preparazione all'esame di Ingegneria del Software 1 per l'università degli Studi di Udine. Voglio ringraziare un utente anonimo che ha messo su dropbox alcune delle FAQ qui presenti. Per qualsiasi domanda/suggerimento scrivetemi a Si illustri il concetto di testing incrementale di integrazione. Si spieghino i due approcci al testing denominati rispettivamente black box e white box. Ch20 Il testing incrementale di integrazione è un tipo di testing in cui i vari sotto componenti vengono inizialmente testati uno ad uno. Una volta che questa fase ha successo si procede ad integrarli, ottenendo così un componente più complesso che viene testato a sua volta, infatti il comportamento del componente così assemblato potrebbe presentare difetti non riscontrabili a livello dei singoli sotto componenti (regression test). Quando tutti i componenti sono stati testati li si unisce nel sistema finito (o in un parte di esso se necessario) che viene testato nella sua interezza. Le varie fasi del testing sono responsabilità di gruppi indipendenti. Gli approcci al testing denominati black box e white box si distinguono per il livello di conoscenza del componente consentito ai responsabili dell'operazione. Nel primo testing essi conoscono solo l'aspetto esterno del componente, ossia l'interfaccia che mette a disposizione, i servizi che fornisce ed il comportamento previsto nei vari casi. Nel secondo caso, che è un testing strutturale, i testers invece conoscono anche i meccanismi con cui i servizi offerti dal componente vengono generati, potendo in questo modo cercare i punti deboli e metterli alla prova. Si presenti il modello generale per il processo di progettazione del software (software design), illustrando le diverse attività ed i loro prodotti nelle varie fasi dalla fine della specificazione all'inizio dell'implementazione.(ch3 slide 41+) Il software design consiste nella traduzione dalle specifiche ad un software eseguibile. in questa fase si sceglie e si progetta una struttura che realizzi le specifiche. in particolare è necessario progettare tutti i vari elementi del software, ossia l'architettura, i livelli di astrazione, le interfacce, i componenti, le strutture dati e gli algoritmi. per ognuno di questi elementi viene quindi prodotta una specifica in linguaggio tecnico adatta ad essere utilizzata da coloro che scriveranno il codice del software Progettazione architetturale in particolare la progettazione architetturale prevede una scomposizione del sistema in sottosistemi, componenti, sotto componenti e così via a seconda dei livelli di astrazione necessari, producendo la descrizione dell'architettura del software. Ci si occupa di definire i servizi offerti dai vari elementi e le modalità di interazione tra di essi. specificazione astratta: per ogni sotto sistema viene prodotta un specificazione astratta dei servizi design dell'interfaccia: per ogni sottosistema di progetta e documenta l'interfacciamento con del altre parti del sistema design dei componenti: allocazione dei servizi e progettazione delle interfacce proprie delle singole componenti design della struttura dati: scelta della struttura dati più adatta per l'implementazione, dettagliata e specificata design dell'algoritmo: vengono definiti gli algoritmi usati per i servizi.

2 Perché è importante capire i requisiti di un sistema software? Quali sono le conseguenze di un cambiamento dei requisiti durante la varie fasi dello sviluppo? Quali sono le possibili cause di tali cambiamenti? Come si possono minimizzare gli effetti negativi di tale fenomeno?(ch6) Capire i requisiti di un sistema software è fondamentale in quando ne dipende la corretta riuscita del prodotto. Poiché i requisiti rappresentano ciò che il committente e/o l'utente si aspetta, un'erronea comprensione dei requisiti implica un software che non risponde alle esigenze di chi lo userà. Sia nel caso di requisiti dettagliati fin dall'inizio, sia quando i requisiti vengono definiti in passi successivi, è importante che ci sia chiarezza e colui che rileva i requisiti deve avere consapevolezza del dominio d'uso del software. I requisisti di un sistema cambiano spesso, anche quando il progetto parte, questo perché gli stakeholders trovano nuovi requisiti oppure perché bisogna negoziare tra più persone un compromesso (chi paga il software non è quasi mai l'utente finale). Le conseguenze di un cambio di requisiti in corso d'opera possono essere ad esempio contraddizioni con quello che era già stato sviluppato o aumenti di complessità nella struttura del sw. tra le cause dei cambiamenti possono esserci nuovi stakeholders, variazioni del target degli utenti, evoluzioni del mercato,... è utile pianificare la gestione dei requisiti: 1. Identificazione dei requisiti, ogni requisito è unico; 2. Gestione del cambio dei requisiti; 3. Politiche di tracciabilità e relazione fra essi; 4. Strumenti CASE usati. Per minimizzare gli effetti negativi è possibile compilare una lista dei requisiti, collegare ogni voce a colui che l'aveva richiesta e documentare quali sono state le scelte dettate dai vari requisiti. In questo modo è possibile riadattare lo sviluppo in maniera oculata e conciliare eventuali requisiti discordi. Per limitare gli effetti negativi di un cambio negativo bisogna studiare il cambio proposto, valutandone la fattibilità, infine analizzare i costi ed effettuare l'implementazione, che dovrà anche andare a modificare il documento dei requisiti. Qual'è il metodo più utilizzato per la verifica statica del software? Come si attua? Che tipo di risultati fornisce? Ha senso pensare di utilizzare solamente tale metodo per la Verifica&Validazione del sistema software? (ch19) Il metodo più utilizzato per la verifica statica del sw è senz'altro l'ispezione. Essa consiste nell'analisi del codice da parte di un team di persone che comprende di solito un coordinatore, coloro che hanno scritto il codice e persone esterne capaci di dare un giudizio tecnico. L'ispezione prevede una lista di errori e sviste comuni che possono essere commessi nella stesura del codice, che vengono così cercati e rimossi; questo tipo di verifica è molto efficace perché non richiede il sistema intero per essere effettuato e consente così di passare alle fasi successive dinamiche (quali testing e debugging) avendo già eliminato gran parte delle possibili fonti di malfunzionamento. Naturalmente non ha senso utilizzare solamente questo metodo poiché così facendo rimarrebbero tutti gli errori non dipendenti dalla natura del codice ma rilevabili solo al momento dell'esecuzione, ad esempio a causa di input scorretti o particolari situazioni dipendenti dallo stato del sistema (rete sovraccarica, memoria limitata,...)

3 Si descrivano le diverse attività svolte nell'ambito della gestione dei progetti software (software project management). Che cosa sono le pietre miliari (milestone)? E le consegne (deliverable)? Quali sono le relazioni fra i due concetti? (ch4) La gestione dei progetti sw si occupa di tutti gli aspetti organizzativi di un progetto sw. a capo di tutto c'è il project manager, che ha la responsabilità di supervisionare il progetto in tutte le fasi, dalla raccolta dei requisiti alla fine del ciclo di vita del sw con la sua dismissione. la gestione prevede quindi: allocazione delle risorse finanziarie, gestione del personale (scelta degli individui, assegnazione dei vari compiti, training,...), pianificazione delle fasi, controllo del regolare svolgimento del processo e soluzione di problemi, stesura di relazioni periodiche, rapporti con i committenti,etc... Le pietre miliari sono prodotti intermedi dell'implementazione del sistema o parte di esso considerate punti definitivi conclusi da cui partire per le fasi di sviluppo successive. quando una pietra miliare può essere consegnata al committente, essa diventa deliverable, ossia un prototipo funzionante e funzionale che può essere utilizzato e valutato dal cliente In che modo il modello dei processi di sviluppo software basato sulla consegna incrementale (incremental development) può essere considerato una via di mezzo tra il modello a cascata (waterfall) e il modello evoluzionistico (evolutionary/prototyping)? Quali criticità supera e quali vantaggi coglie degli altri due modelli? (ch3,pag72) Il modello a consegna incrementale è una via di mezzo perché pur attenendosi alle varie fasi del processo come il modello a cascata, si basa su incrementi che possono essere considerati evoluzioni del sistema. Questo permette di: mantenere una buona struttura del codice in quanto una volta definiti bene i requisiti si parte con un approccio simil-waterfall; permette di definire bene i requisiti in quanto i requisiti vengono raccolti e definiti con un approccio evoluzionistico; il cliente può utilizzare sin da subito (testandole maggiormente) le funzionalità più importanti; Una fase viene superata quando è definitiva come nel modello a cascata, ma richiede meno tempo in quanto non è l'intero sistema ad essere sviluppato ma i suoi blocchi componenti, ed i risultati non vengono buttati via come nel prototyping di tipo throw-away Si illustrino l'input e l'output dei seguenti due processi software: (i) l'iniziale deduzione/elicitazione & analisi dei requisiti (requirements elicitation & analysis) e (ii) la successiva specifica(zione) dei requisiti (requirements specification). B. Si illustrino le tipologie di notazioni/linguaggi di modellizzazione utilizzati nei due casi, evidenziando i limiti e le criticità delle soluzioni adottate nel processo (i), che giustificano l'adozione di linguaggi (anche) diversi per il processo (ii)? (ch6&ch7) Per la validazione dell'affidabilità viene utilizzato un testing dinamico denominato testing statistico. esso prevede l'esecuzione ripetuta del sw, durante la quale vengono contati errori e malfunzionamenti. questo tipo di testing quantifica l'affidabilità del sw e in base al livello di affidabilità da raggiungere determina se è necessario procedere con un'ulteriore fase di miglioramento. I casi di test con cui avvengono le esecuzioni del programma sono basate sui cosiddetti profili operativi, ossia insiemi di dati creati per il testing la cui frequenza rispecchia quella con cui tali dati vengono forniti in input al sistema durante l'uso normale previsto.

4 Cos'è e quando si usa il path testing (testing dei percorsi)? B. Quali sono i suoi limiti? Come si può a priori stimare il numero di casi di test necessari per la sua esecuzione? (ch20) Il path testing si usa quando si ha a che fare con il testing dei singoli componenti. L'idea di base è quella di testare ogni possibile percorso di esecuzione del codice andando a sollecitare le istruzioni di condizione ivi presenti (if, cicli while, for, case, etc...). Il limite è chiaramente dettato dal numeri di questi percorsi: relativamente limitato per un (piccolo) componente, ma molto alto per più componenti messi assieme. Si può stimare il numero di persorsi necessari calcolando la complessità Ciclotomica, che è di un'unità superiore al numero di condizioni elementari presenti nel codice; per condizione elementare si intende una singola condizione booleana, cioè non composta con connettivi logici (and, or), per le condizioni composte bisogna calcolare il numero di condizioni semplici. Nell'ambito della validazione dell'affidabilità (reliability validation) quale tipo di testing viene utilizzato e come si effettua? Cos'è un profilo operativo (operational profile) e come viene usato? (ch19) In questi ambiti si deve verificare per se stessi e per il cliente che il sistema ha raggiunto il grado di fidatezza voluto. Per fare questo esistono sia tecniche dinamiche che statiche. Quelle statiche sono sempre le stesse, per quello dinamiche invece si può: testare il prodotto secondo dei profili operativi; testare il prodotto a run-time nell'ambiente in cui verrà usato (ndr l'azienda che l'ha chiesto). Questo processo si divide in quattro fasi: ricerca dei profili operativi effettuata studiando come verrà usato il sw; si costruisce un insieme di dati per testare ogni profilo operativo; si eseguono i test per ogni dato dell'insieme e per tutti gli insiemi; dopo aver eseguito un numero di test statisticamente valido di valuta l'affidabilità raggiunta. Presenta gli ovvi problemi del capire qual'è il numero statisticamente rilevante e del fatto che questi test possono essere difficili da trovare. Il profilo operativo dovrebbe riflettere come il sistema verrà usato nella realtà, associando ai possibili input i rispettivi output forniti dal sw; si deve anche associare la probabilità con cui questi input verranno forniti al programma. Molto difficile trovarli per i sistemi interattivi dove i possibili input possono essere elevati. Si illustri il concetto di fidatezza (dependability) del software. Quali sono le sue 4 componenti principali? Come varia il costo del software all'aumentare del livello di dependability e perché? (ch16) La fidatezza rispecchia il giudizio degli utenti relativamente a quanto essi si fidano del sistema, specialmente se critico, ossia la loro fiducia nel fatto che il sw offrirà loro il servizio richiesto senza fallimenti e con tempi di reazione/risposta ragionevoli. questo parametro è prettamente soggettivo, infatti un sw oggettivamente utile e funzionante non ha necessariamente un punteggio alto di fidatezza. Gli attributi che lo compongono sono: 1. Disponibilità, possibilità che il sistema fornisca il servizio quando richiesto; 2. Affidabilità, abilità del sistema di fornire i servizi come specificato; 3. Sicurezza, abilità del sistema di operare senza danni a cose e persone; 4. Protezione, abilità del sistema a proteggersi contro intrusioni. Il costo del sw aumenta con il livello di fidatezza in quanto richiede tecniche più costose e un incremento di v&v, specialmente le fasi di testing, per dimostrare all'utente la fidatezza raggiunta.

5 Cos'è un modello di qualità del software? Si elenchino le principali caratteristiche di qualità di un generico modello di qualità. (Quality ISO Standards) Un modello di qualità del sw è un insieme di regole che devono essere rispettate in tutte le fasi del processo sw e di attributi che deve possedere un prodotto sw: 1. Affidabilità: abilità del sistema a fornire i servizi come specificato; 2. Efficienza: uso sensato delle risorse entro tempi ragionevoli; 3. Manutenibilità: adattabilità alle modifiche nel tempo, stabilità nel tempo; 4. Funzionalità: utilità dei servizi forniti, capacità di interagire con altri sw; 5. Usabilità: facilità e comprensione delle interfacce. Si definiscano i processi di verifica e validazione del software. Quali diverse attività di validazione vengono svolte nelle diverse fasi del ciclo di vita? (ch19) I processi di verifica e validazione vengono svolti in seguito alla fase di implementazione e codifica, una o più volte e con target diversi a seconda del metodo di sviluppo adottato. Il primo risponde alla domanda se il sw è un prodotto fatto bene che rispetta le specifiche, mentre il secondo si preoccupa di controllare che il sw faccia quello che l'utente richiede. le attività di validazione sono l'ispezione statica (controllo dei requisiti, codice,...), l'esecuzione diretta del sw (beta testing, testing statistico, simulazioni) e la proto tipizzazione dinamica Nelle varie fasi di vita si possono validare: 1. i requisiti non appena sono stati definiti; 2. eventualmente i vari incrementi, per validare i requisiti relativi alla parte di codice implementata; 3. nelle fasi finali nella fase di collaudo per verificare che tutto corrisponda al documento dei requisiti. Si illustri cosa sono e a cosa servono le partizioni di equivalenza utilizzate nel testing. Si descriva come si progettano nel caso del testing strutturale (white-box) (ch20) Le partizioni di equivalenza sono insiemi di valori di input raggruppati in base al fatto che producono comportamenti e/o output simili in un determinato componente o funzione. Esse sono strettamente collegate al testing strutturale white box perché sono create conoscendo la struttura interna del codice, che ci permette appunto di definire l'insieme della partizioni. Il loro uso tipico è quello di mettere alla prova il componente dandogli in input valori di confine tra due partizioni e per verificare che il comportamento sia effettivamente differente e gli output stiano a loro volta in partizioni distinte Alcuni esempi: controllare input errati e sbagliati per testare i controlli sugli input del codice; in algoritmi tipo ricerca binaria inserire l'elemento in prima, ultima e mediana posizione; sempre negli algoritmi di ricerca inserire o meno l'elemento voluto nella sequenza da controllare; se un programma accetta input positivi da 0 a 100 provare e passare 0, 100, un numero nell'intervallo, uno molto grande e uno negativo. Cos'è il software prototyping? In quali situazioni si utilizza e perché? Come si esegue? (ch3) Il software prototyping viene utilizzato quando i requisiti sono stati capiti male o c'è la possibilità che siano ambigui. Consiste nel generare dei sistemi grezzi da presentare al cliente, in modo tale che lui possa capire se fa o meno quello che vuole, e in caso contrario possa proporre le giuste modifiche.

6 Dato che sono sistemi grezzi non comportano un grande lavoro e anche distruggerli non comporta grandi perdite economiche. Cosa significa Gestione della Qualità? Quali sono i processi principali della gestione della qualità? Cos'è lo standard ISO 9000? (Quality ISO) La gestione della qualità è in generale un insieme di operazioni da effettuare e comportamenti da seguire affinché un prodotto venga considerato di qualità; nel campo del sw la gestione della qualità accompagna il prodotto in tutto il ciclo di vita, dalla raccolta dei requisiti fino alla dismissione, e prevede una figura o una squadra di persone che si occupi di tutti gli aspetti riguardanti la qualità. I processi principali della gestione della qualità controllano il processo software nella sua interezza, con particolare focalizzazione sulle fase di verifica e validazione. tali controlli sono schedulati periodicamente e si traducono in documenti in cui i responsabili approvano l'operato degli sviluppatori o esprimono critiche (possibilmente costruttive) per far rientrare il lavoro negli standard di qualità scelti. ISO 9000 è una famiglia di standard che contiene tutte le linee guida per i sistemi di gestione della qualità. l'iso rappresenta il documento dedicato alla qualità del sw Si illustri il concetto di requisiti software (tipologie, livello di dettaglio, prospettiva,...). Quali sono le differenze tra il processo di definizione dei requisiti e quello di specificazione dei requisiti? (ch6) I requisiti sw rappresentano i servizi che un sw deve fornire e le modalità con cui vengono prestati. possono essere categorizzati in base a vari aspetti. Si distinguono in: funzionali: ossia che funzionalità deve offrire il sistema; non funzionali: che vincolo vengono imposti sulle funzionalità. Una seconda distinzione è quella tra requisiti dell'utente, cioè specifiche caratteristiche richieste da chi andrà ad operare con il sw, requisiti del sistema, come ad esempio la necessità di girare su SO o piattaforme hw fissate, e requisiti di dominio, che in generale comprendono entrambe le categorie precedenti e derivano dall'ambiente in cui il sw verrà utilizzato. I requisiti si dividono in livelli di dettaglio potenzialmente infiniti (la richiesta di un particolare servizio di differenzia dal puntualizzare le modalità con cui si vuole che tale servizio venga offerto). I requisiti possono infine essere differenziati secondo il punto di vista che esprimono. i punti di vista più comuni sono quelli del committente, dell'utilizzatore, del sistema e del progettista. Il processo di definizione, quindi, è il processo di raccolta dei requisiti. Aumentando man mano il livello tecnico dei requisiti si arriva alla definizione delle specifiche software, che guardano più a come il sistema deve essere fatto. Si illustri il processo di sviluppo del software che prevede una consegna incrementale. Si fornisca un modello del processo (in sotto processi) e se ne illustrino vantaggi e problemi. (ch3) Nel processo a consegna incrementale vengono consegnate al cliente diverse versioni del software incompleto in modo che lui le possa usare e testare per vedere se corrispondono alle sue reali esigenze. La struttura generale è: definizione dei requisiti; vari incrementi in cui vengono implementate via via tutte le cose partendo da quelle importanti, che in questo modo verranno testate maggiormente; l'incremento finale che comprende anche le fasi di verifica e convalida. Il vantaggio principale è che il cliente può capire quali sono le sue reali esigenze e questo si traduce in una maggiore comprensione dei requisiti stessi. Lo svantaggio è che la struttura del software, a causa delle continue modifiche, può diventare complessa e difficilmente gestibile dopo pochi passaggi.

7 Si illustri il modello a spirale per i processi software? Quale ruolo ha l'analisi del rischio in tale modello? Come si rapporta il modello con altri modelli generali dei processi software. Il modello a spirale è un tipo di modello iterativo in cui l'analisi del rischio e la pianificazione sono considerati di primaria importanza. In ogni ciclo della spirale sono appunto previsti l'impostazione degli obiettivi, la definizione dei rischi, la ricerca delle modalità per ridurli al minimo e la scelta del modello per la componente in corso di sviluppo. Così facendo si garantisce che eventuali problemi non si amplifichino a dismisura perché è teoricamente sempre possibile ritornare ad un punto precedente della spirale in backtracking. In un certo senso si potrebbe affermare che il modello a spirale è simile ad un modello incrementale con sotto fasi non rigidamente separate, in cui però il rischio e la pianificazione vengono messi in primo piano. Si descrivano gli scopi delle principali attività cui si dedica il manager di un progetto software. Quali sono le differenze tra il concetto di milestone e di deliverable? C'è fra i due concetti una corrispondenza biunivoca? (ch4) Le attività principali del manager sono: controllare che i tempi e le consegne siano rispettati: controllare che i costi non subiscano cambiamenti radicali; gestire il personale, eventualmente valutare se assumerne di nuovo; scrittura di una proposta per un appalto; scritture e presentare i report del progetto. La principale differenza fra milestone e deliverable è: le milestone sono dei punti importanti del progetto, quali la stesura finale del documento dei requisti, la fine di un sottosistema o la fine del progetto stesso; i deliverable sono delle parti del processo che è utile consegnare al cliente. Può benissimo essere una prima versione del sistema o di un suo sottosistema. Non c'è una corrispondenza biunivoca fra le due perché sì i deliverable sono solitamente delle milestone, ma il contrario non è detto (difficilmente un cliente ha interesse a vedere la fine di un processo di progettazione architetturale...). Si descrivano i prodotti del processo di progettazione architetturale. Quali diverse prospettive/decisioni sull'architettura del sistema devono venir considerate in fase di progettazione? (ch10) Tra le scelte della progettazione architetturale troviamo tre aspetti da considerare: la strutturazione del sistema in più sottosistemi (parti indipendenti), si può scegliere se usare un modello repository (DB condiviso) oppure un'architettura client-server; La strutturazione dei sottosistemi in moduli (parti dipendenti), si può scegliere fra modelli ad oggetti o orientati alle funzioni (trasformazione dai dati); Definire il modello di controllo fra i vari sottosistemi, si può scegliere fra: l'approccio centralizzato con un componente che fa da manager o un modello call-return (gerarchia del controllo top-down) oppure su un approccio bastato sugli eventi dove il controllo viene guidato da eventi trasmessi in broadcast o catturati con tecniche in stile interrupt-driven. Altri punti di vista sono la protezione (gli aspetti più critici vengono sviluppati in livelli interni non direttamente accessibili), la sicurezza (isolamento dei componenti fondamentali), la disponibilità (aggiungere ridondanza in caso di guasti) e la manutenibilità (utilizzo di componenti piccoli ed autosufficienti.

8 A quale tipologia di testing appartengono gli approcci del testing top-down e bottom-up? In cosa consistono? Se ne confrontino le caratteristiche Appartengono al test del sistema, in quanto permettono di testare il sistema (sottosistema) in maniera globale. Le loro caratteristiche sono: top-down: testa per prime le funzionalità più esterne al sistema, sostituendo le componenti interne con degli stub (parti di codice che coprono il buco senza fare nulla di utile, per esempio possono dire Ok, sono stato chiamato. Poi si scende man mano integrando le parti mancanti fino ad arrivare ad averle integrate tutte; bottom-up: il contrario, si testano prima le parti più interne e poi si aggiungono parti più esterne fino a che non si è arrivati al livello superiore. In pratica si utilizza un metodo ibrido che consente di testare prima le funzionalità più importanti (che quindi verranno di fatto testate più a lungo) e poi quelle meno importanti (che verranno integrate nelle fasi finali e riceveranno meno attenzione). Cosa significa architettura distribuita? Quali sono i principali tipi di architetture a strati (tier-architecture) e come si differenziano? Cos è il middleware? Sono quei sistema la cui elaborazione è distribuita su più macchine. Esistono tre strati: presentazione dei dati e raccolta input: vedi interfacce grafiche e/o web; elaborazione dei dati: fornisce le funzionalità dell'applicazione; gestione e controllo dei dati. Il tipo più comune è quello client-server (two-tier), che si può scomporre in due tipi: thin-client: nel client rimane solo la parte di presentazione dei risultati e di raccolta input; presenta il particolare svantaggio di sottoutilizzare la potenza del client; fat-client: nel client abbiamo anche l'elaborazione dei dati, lasciando di fatto nel server la sola gestione dei dati; di più complessa gestione in quanto il cambio del codice va effettuato sia sul client che sul server (risolto con le applet). Nelle architetture tier, di due grossi tipi abbiamo di fatto una maggiore suddivisione dei tre strati: three-tier: ogni strato viene gestito da un sistema/computer diverso; multi-tier: uno strato può essere gestito da una o più macchine: ad esempio un server gestisce le richieste ai dati che poi verranno smistate a più server, ognuno con un proprio db. Il middleware è un software, solitamente già pronto, che gestisce la comunicazione fra le macchine presenti nella rete, in quanto tali macchine possono avere protocolli e implementazioni diverse. Si definiscano ed illustrino i concetti di affidabilità e di disponibilità del software. Si illustrino le metriche utilizzabili per misurare affidabilità e di disponibilità del software? L'affidabilità è la probabilità che si verifichi un guasto nel compimento di un'azione. La disponibilità invece è la probabilità che il sistema sia attivo e funzionante quando l'utente richiede i suoi servizi. Le metriche utilizzabili sono: ROCOF (Rate of Occurence of Failure): il numero di guasti nell'unità di tempo; PODOF (Probability of Failure on Demand): il numero di richieste di servizio negate nell'unità di tempo; MTBF: il tempo medio fra i guasti, utile nei sistemi che sono usati intensivamente e per periodi di tempo lunghi; AVAIL: la disponibilità (availability) del sistema a fornire i servizi nell'unità di tempo.

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

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

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

Sistemi Informativi I Lezioni di Ingegneria del Software

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

Dettagli

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

Verifica e validazione della qualità del sw

Verifica e validazione della qualità del sw Verifica e validazione della qualità del sw Tecniche di Programmazione Lez. 07 Università di Firenze a.a. 2009/10, I semestre 1/40 contenuti Termini e definizioni Tecniche rispetto alle caratteristiche

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

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

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

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

Lo Studio di Fattibilità

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

Dettagli

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

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

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

Dettagli

Il ciclo di vita del software

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

Dettagli

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

Collaudo e qualità del software Quali test eseguire

Collaudo e qualità del software Quali test eseguire Collaudo e qualità del software Relatore Ercole Colonese Roma, Tipologie di test Temi trattati nel libro Modello a V Livelli di testing Tipi di test Test funzionali Test delle funzionalità Test di gestione

Dettagli

Testing. Definizioni. incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell uso di strumenti

Testing. Definizioni. incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell uso di strumenti Definizioni Problemi del testing:criterio di selezione dei casi di test Test Funzionale: suddivisione in classi di equivalenza e analisi dei valori limite Test Strutturale: basato sul flusso di controllo

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

Il ciclo di vita del software. La necessita` di un modello. La mancanza di un modello. La prima proposta di soluzione

Il ciclo di vita del software. La necessita` di un modello. La mancanza di un modello. La prima proposta di soluzione Il ciclo di vita del software Progettazione e implementazione è solo una fase, per quanto importante, della produzione industriale del software Altre fasi sono importanti. Ad esempio: h Analisi dei requisiti

Dettagli

La disciplina che cura un approccio sistematico, disciplinato e quantificabile allo sviluppo, all operatività ed alla manutenzione del software

La disciplina che cura un approccio sistematico, disciplinato e quantificabile allo sviluppo, all operatività ed alla manutenzione del software Ingegneria del software (software engineering) La branca dell'ingegneria che si occupa della realizzazione di sistemi software. La disciplina che cura un approccio sistematico, disciplinato e quantificabile

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

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

3. DOCUMENTO DI DEFINIZIONE DEI REQUISITI FORNITO DAL CLIENTE 3.1 Richieste del cliente

3. DOCUMENTO DI DEFINIZIONE DEI REQUISITI FORNITO DAL CLIENTE 3.1 Richieste del cliente T4 Contenuto di un analisi dei requisiti Presentate un indice di un documento di analisi dei requisiti e descrivete in modo sintetico contenuto e ruolo di ogni capitolo. INDICE 1. STORIA DELLE REVISIONI

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

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

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

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

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

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

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

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

Dettagli

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

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

Dettagli

Principi dell ingegneria del software Relazioni fra

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

Dettagli

Giuseppe Santucci. Qualità nella Produzione del Software

Giuseppe Santucci. Qualità nella Produzione del Software Giuseppe Santucci Qualità nella Produzione del Software 03 Revisione del contratto (Contract review) & Piani di sviluppo e qualità (Development and quality plans) 03CR&DQP.1 Contract review? Una cattiva

Dettagli

7. Architetture Software

7. Architetture Software 7. Architetture Software progettare la struttura Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 7. Architetture Software 1 / 20 Scopo della fase di design

Dettagli

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Mystic Pizza Gestione Pizzeria Scheda di Progetto Version 1.0 Data 19/03/2007 Indice degli argomenti 1. Introduzione 3 a. Scenario

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

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

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

Negro Giulio Del Mutolo Nicola CORSO DI SISTEMI PER L ELABORAZIONE DELL INFORMAZIONE: GESTIONE DI RETE

Negro Giulio Del Mutolo Nicola CORSO DI SISTEMI PER L ELABORAZIONE DELL INFORMAZIONE: GESTIONE DI RETE Definizione di un'architettura client/server basata su SNMP per il monitoraggio del traffico che passa attraverso n router utilizzati per connettere un'azienda ad Internet. Negro Giulio Del Mutolo Nicola

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

Finalità del ciclo di vita nel System Engineering

Finalità del ciclo di vita nel System Engineering Fasi del ciclo di vita overview Finalità del ciclo di vita nel System Engineering Modularità Individuazione più agevole delle componenti riutilizzabili Ciclo di vita Esaustività Certezza di coprire tutte

Dettagli

Testing: basato su analisi dinamica del codice. Metodi Formali: basato su analisi statica del codice.

Testing: basato su analisi dinamica del codice. Metodi Formali: basato su analisi statica del codice. Convalida: attività volta ad assicurare che il SW sia conforme ai requisiti dell utente. Verifica: attività volta ad assicurare che il SW sia conforme alle specifiche dell analista. Goal: determinare malfunzionamenti/anomalie/errori

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

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

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

Corso di Progettazione di sistemi multimediali

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

Dettagli

REFERENZIAZIONI 2001) NUP

REFERENZIAZIONI 2001) NUP Agenzia del Lavoro Provincia Autonoma di Trento PROFILO FORMATIVO Profilo professionale e percorso formativo DENOMINAZIONE FIGURA PROFESSIONALE - TECNICO INFORMATICO PROGRAMMATORE SOFTWARE E APPLICAZIONI

Dettagli

13: Il test del software. 13Test.1

13: Il test del software. 13Test.1 13: Il test del software 13Test.1 Concetti fondamentali Costo estremamente elevato Filosofia distruttiva Eseguire un programma con l intento di trovare degli errori; Un caso di test e ben studiato se ha

Dettagli

Linguaggi di programmazione

Linguaggi di programmazione Linguaggi di programmazione Programmazione L attività con cui si predispone l elaboratore ad eseguire un particolare insieme di azioni su particolari dati, allo scopo di risolvere un problema Dati Input

Dettagli

Verifica e Convalida

Verifica e Convalida Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Verifica e Convalida E. TINELLI Definizioni Le attività di Verifica (Verification) e Convalida (Validation)

Dettagli

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra.

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra. Appunti di Calcolatori Elettronici Modello di macchina multilivello Introduzione... 1 Linguaggi, livelli e macchine virtuali... 3 La struttura a livelli delle macchine odierne... 4 Evoluzione delle macchine

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

Sintesi dei punti da ricordare di Ingegneria del software (1300 diapositive in 15 pagine) Silvio Moioli

Sintesi dei punti da ricordare di Ingegneria del software (1300 diapositive in 15 pagine) Silvio Moioli Sintesi dei punti da ricordare di Ingegneria del software (1300 diapositive in 15 pagine) Silvio Moioli Definizioni di base Ingegneria del software: l'approccio sistematico allo sviluppo, all'operatività,

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

Ingegneria del Software Progettazione

Ingegneria del Software Progettazione Ingegneria del Software Progettazione Obiettivi. Approfondire la fase di progettazione dettagliata che precede la fase di realizzazione e codifica. Definire il concetto di qualità del software. Presentare

Dettagli

Software Engineering & Re-Engineering Metodologie, Tecniche e Tools applicate alla produzione del software per ambienti Industriali e di Ricerca

Software Engineering & Re-Engineering Metodologie, Tecniche e Tools applicate alla produzione del software per ambienti Industriali e di Ricerca Software Engineering & Re-Engineering Metodologie, Tecniche e Tools applicate alla produzione del software per ambienti Industriali e di Ricerca Docente : Ing. Secondulfo Giovanni Anno Accademico 2009-2010

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

Linee guida per lo sviluppo e la gestione di un sito Web

Linee guida per lo sviluppo e la gestione di un sito Web Linee guida per lo sviluppo e la gestione di un sito Web Paolo Atzeni Università Roma Tre Dipartimento di Informatica e Automazione atzeni@dia.uniroma3.it http://www.dia.uniroma3.it/ atzeni/ Roma, 25 settembre

Dettagli

ITAlian Software Testing Qualifications Board Simulazione d Esame. Livello Foundation. Versione 2011

ITAlian Software Testing Qualifications Board Simulazione d Esame. Livello Foundation. Versione 2011 ITAlian Software Testing Qualifications Board Simulazione d Esame Livello Foundation Versione 2011 DATI IDENTIFICATIVI CODICE DOCUMENTO DATA DI EMISSIONE STATO ITASTQB-EXAMSIM-FOUND-01 15/01/2012 REDATTA

Dettagli

Software per la gestione di musei di arte contemporanea1

Software per la gestione di musei di arte contemporanea1 Software per la gestione di musei di arte contemporanea1 Identificativo del progetto: CA Nome documento: System Design(SD) Identificativo del documento: 6 CA_SD_E1_R1 Data del documento: 21/05/2012 Prima

Dettagli

La progettazione del software nelle piccole o micro imprese

La progettazione del software nelle piccole o micro imprese La progettazione del software nelle piccole o micro imprese Il contenuto di questo documento è strettamente confidenziale, la visione dello stesso è consentita solo al personale di FadeOut Snc e della

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

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

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

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

Dettagli

Sistemi Informativi I Lezioni di Ingegneria del Software

Sistemi Informativi I Lezioni di Ingegneria del Software 1 Introduzione all Ingegneria del Software. In questa prima parte viene definita l Ingegneria del Software o Software Engineering (SWE), vengono presentate le caratteristiche del ciclo di vita di un prodotto

Dettagli

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

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

Dettagli

WHIT E PAPER. skipper

WHIT E PAPER. skipper WHIT E PAPER skipper Giugno 2003 schedulatore a capacità finita Skipper è un programma di elevato contenuto tecnologico che non richiede particolari installazioni. Si interfaccia con la base dati (comune

Dettagli

Ingegneria del Software

Ingegneria del Software Ingegneria del Software Testing - Strategie di del Software Testing del Software Il testing è quell attivit attività di esercizio del software tesa all individuazione dei malfunzionamenti prima della messa

Dettagli

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

Architetture e applicazioni web

Architetture e applicazioni web Architetture e applicazioni web L o Guido Porruvecchio Tecnologia e Applicazioni della Rete Internet Cosa è un'applicazione web E' un particolare tipo di applicazione che si appoggia sulle tecnologie,

Dettagli

Il Processo di Omologazione in ambito di segnalamento ferroviario a tecnologia innovativa

Il Processo di Omologazione in ambito di segnalamento ferroviario a tecnologia innovativa Roma, 10 novembre 2008 Il Processo di Omologazione in ambito di segnalamento ferroviario a tecnologia innovativa Ing. Gabriele Ridolfi RFI Direzione Tecnica Mail: g.ridolfi@rfi.it Processo Omologativo:

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

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

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

Software testing. Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it. A.A. 2010-2011 Autori: A.Bei/F.Rabini/F.

Software testing. Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it. A.A. 2010-2011 Autori: A.Bei/F.Rabini/F. 1 Software testing Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it A.A. 2010-2011 Autori: A.Bei/F.Rabini/F.Spiga 2 Functional Testing Sotto la dicitura funzionale si raccolgono i criteri

Dettagli

Esercizi su. Funzioni

Esercizi su. Funzioni Esercizi su Funzioni ๒ Varie Tracce extra Sul sito del corso ๓ Esercizi funz_max.cc funz_fattoriale.cc ๔ Documentazione Il codice va documentato (commentato) Leggibilità Riduzione degli errori Manutenibilità

Dettagli

1. L Ingegneria del Software

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

Dettagli

uomo Software (sistema operativo) hardware

uomo Software (sistema operativo) hardware uomo Software (sistema operativo) hardware 1 Sistema operativo Insieme di programmi che svolgono funzioni essenziali per l uso del sistema di elaborazione Questi programmi sono i primi ad essere eseguiti

Dettagli

La documentazione del progetto (p.278)

La documentazione del progetto (p.278) La documentazione del progetto (p.278) La qualità di un progetto viene valutata anche in base alla documentazione acclusa. I benefici di una buona documentazione sono sempre tangiili. La documentazione

Dettagli

Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa. La mia scuola ha un sito Web

Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa. La mia scuola ha un sito Web Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa La mia scuola ha un sito Web Presentazione del corso Contenuti e obiettivi del corso Imparare a lavorare con le metodologie dell ingegneria del

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

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

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

Dettagli

-Sistemi per il rilevamento di flussi di persone- Progetto:

-Sistemi per il rilevamento di flussi di persone- Progetto: -Sistemi per il rilevamento di flussi di persone- Progetto: Sistema per il rilevamento e l analisi dei flussi dei clienti in un megastore di 1 piano di 1250m 2, composto da 20 corsie di 1m di lunghezza

Dettagli

Architetture Software

Architetture Software Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software Architetture Software Giulio Destri Ing. del Sw: Architettura - 1 Scopo del modulo

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

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

12. FONDAMENTI DI INGEGNERIA DEL SOFTWARE

12. FONDAMENTI DI INGEGNERIA DEL SOFTWARE 12. FONDAMENTI DI INGEGNERIA DEL SOFTWARE PREMESSA La produzione del software non può essere affidata all improvvisazione: sapere scrivere algoritmi e programmi non garantisce di per se l avere un software

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

CAPITOLO 5. Gestione dell'ambito del progetto

CAPITOLO 5. Gestione dell'ambito del progetto CAPITOLO 5 Gestione dell'ambito del progetto 5 La gestione dell ambito di progetto comprende i processi necessari ad assicurare che il progetto includa tutto il lavoro richiesto, e soltanto il lavoro richiesto,

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Programmazione per Bioinformatica Il Calcolatore e la Programmazione. Dr Damiano Macedonio Università di Verona

Programmazione per Bioinformatica Il Calcolatore e la Programmazione. Dr Damiano Macedonio Università di Verona Programmazione per Bioinformatica Il Calcolatore e la Programmazione Dr Damiano Macedonio Università di Verona Architettura del calcolatore La prima decomposizione di un calcolatore è relativa a due macrocomponenti:

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

PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16

PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16 PROGRAMMAZIONE ANUALE DEL DIPARTIMENTO DI INFORMATICA E TELECOMUNICAZIONI ISTITUTO TECNICO a.s. 2015-16 SECONDO BIENNIO Disciplina: INFORMATICA La disciplina Informatica concorre a far conseguire allo

Dettagli

Qualità e Sicurezza A cura di Aicq e Anfia. Torino, Lingotto Fiere 18 aprile 2013

Qualità e Sicurezza A cura di Aicq e Anfia. Torino, Lingotto Fiere 18 aprile 2013 18 aprile 2013 L'Affidabilità e la sicurezza nell'automotive: presente e futuro Dr.ssa Silvia Durando - Dr. Franco Guazzotti - IVECO Prof. Mario Vianello - Politecnico di Torino - Ingegneria dell'autoveicolo

Dettagli

Fondamenti di Informatica 7. Linguaggi di programmazione

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

Dettagli

Gestione dei Progetti (2005-2006)

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

Dettagli

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207.

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207. Durante le attività di sviluppo del software applicativo è spesso utilizzato un ciclo di vita incrementale il cui schema di processo è sintetizzato nella figura seguente. In legenda sono riportate le fasi

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Lezione 3 Martedì 15-10-2013 1 Struttura ed organizzazione software dei sistemi

Dettagli

Il calcolatore oggi : UN SISTEMA DI ELABORAZIONE

Il calcolatore oggi : UN SISTEMA DI ELABORAZIONE Il calcolatore oggi : UN SISTEMA DI ELABORAZIONE hardware Firmware, software memorizzato su chip di silicio Sistema Operativo venduto con l, comprende vari programmi di gestione del sistema Applicativo,

Dettagli