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.

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

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

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

Dettagli

Il ciclo di vita del software

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

Dettagli

Cos è l Ingegneria del Software?

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

Dettagli

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

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

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

Dispense di Informatica Anno Scolastico 2008/2009 Classe 3APS. Dal Problema all'algoritmo

Dispense di Informatica Anno Scolastico 2008/2009 Classe 3APS. Dal Problema all'algoritmo stituto Tecnico Statale Commerciale Dante Alighieri Cerignola (FG) Dispense di nformatica Anno Scolastico 2008/2009 Classe 3APS Dal Problema all'algoritmo Pr.: 001 Ver.:1.0 Autore: prof. Michele Salvemini

Dettagli

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE

PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE PROPOSTE SISTEMA DI CITIZEN RELATIONSHIP MANAGEMENT (CRM) REGIONALE Versione 1.0 Via della Fisica 18/C Tel. 0971 476311 Fax 0971 476333 85100 POTENZA Via Castiglione,4 Tel. 051 7459619 Fax 051 7459619

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

Configuration Management

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

Dettagli

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

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

Dettagli

Business Process Management

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

Dettagli

DataFix. La soluzione innovativa per l'help Desk aziendale

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

Dettagli

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

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

Dettagli

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE In un mercato delle Telecomunicazioni sempre più orientato alla riduzione delle tariffe e dei costi di

Dettagli

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

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

Dettagli

Master Universitario di II livello in PROJECT MANAGEMENT: MANAGING COMPLEXITY a.a. 2014/2015 MANIFESTO DEGLI STUDI

Master Universitario di II livello in PROJECT MANAGEMENT: MANAGING COMPLEXITY a.a. 2014/2015 MANIFESTO DEGLI STUDI Master Universitario di II livello in PROJECT MANAGEMENT: MANAGING COMPLEXITY a.a. 201/2015 MANIFESTO DEGLI STUDI Art. 1 - Attivazione e scopo del Master 1 E' attivato per l'a.a. 201/2015 presso l'università

Dettagli

Intrusion Detection System

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

Dettagli

CA Process Automation

CA Process Automation CA Process Automation Glossario Release 04.2.00 La presente documentazione, che include il sistema di guida in linea integrato e materiale distribuibile elettronicamente (d'ora in avanti indicata come

Dettagli

GoBus: Progettazione e Sviluppo di un App a Supporto della Mobilità

GoBus: Progettazione e Sviluppo di un App a Supporto della Mobilità GoBus: Progettazione e Sviluppo di un App a Supporto della Mobilità Gemma Catolino, Elisa D Eugenio, Davide De Chiara, Alessandro Longo Dipartimento di Studi e Ricerche Aziendali - Management & Information

Dettagli

UML Component and Deployment diagram

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

Dettagli

Business Process Redesign

Business Process Redesign Business Process Redesign I servizi offerti da Nòema 1 Riorganizzare le strutture organizzative significa cercare di conciliare l efficienza delle attività con le aspettative delle persone che costituiscono

Dettagli

1. QUAL È LO SCOPO DI QUESTO MODULO?

1. QUAL È LO SCOPO DI QUESTO MODULO? Percorso B. Modulo 4 Ambienti di Apprendimento e TIC Guida sintetica agli Elementi Essenziali e Approfondimenti (di Antonio Ecca), e slide per i formatori. A cura di Alberto Pian (alberto.pian@fastwebnet.it)

Dettagli

INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML

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

Dettagli

Supporto alle decisioni e strategie commerciali/mercati/prodotti/forza vendita;

Supporto alle decisioni e strategie commerciali/mercati/prodotti/forza vendita; .netbin. è un potentissimo strumento SVILUPPATO DA GIEMME INFORMATICA di analisi dei dati con esposizione dei dati in forma numerica e grafica con un interfaccia visuale di facile utilizzo, organizzata

Dettagli

Corso di Programmazione ad Oggetti

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

Dettagli

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

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

Dettagli

2- Identificazione del processo. (o dei processi) da analizzare. Approcci: Esaustivo. In relazione al problema. Sulla base della rilevanza

2- Identificazione del processo. (o dei processi) da analizzare. Approcci: Esaustivo. In relazione al problema. Sulla base della rilevanza PROCESS MAPPING (2) Approcci: 2- Identificazione del processo Esaustivo (o dei processi) da analizzare Mappatura a largo spettro (es.: vasta implementazione di un ERP) In relazione al problema ad es. i

Dettagli

Modello OSI e architettura TCP/IP

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

Dettagli

ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE

ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE Roma, dicembre 1999 Analisi dei rischi in un progetto di sviluppo sw RISCHIO = potenziale difetto il cui verificarsi comporta dei danni Danno Non

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

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

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

La piattaforma IBM Cognos

La piattaforma IBM Cognos La piattaforma IBM Cognos Fornire informazioni complete, coerenti e puntuali a tutti gli utenti, con una soluzione economicamente scalabile Caratteristiche principali Accedere a tutte le informazioni in

Dettagli

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

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

Dettagli

Business Process Reengineering

Business Process Reengineering Business Process Reengineering AMMISSIONE ALL'ESAME DI LAUREA Barbagallo Valerio Da Lozzo Giordano Mellini Giampiero Introduzione L'oggetto di questo lavoro riguarda la procedura di iscrizione all'esame

Dettagli

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

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

Dettagli

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

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

Dettagli

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

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

Dettagli

Ricognizione di alcune Best Practice

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

Dettagli

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

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

Dettagli

Sempre attenti ad ogni dettaglio Bosch Intelligent Video Analysis

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

Dettagli

SEZIONE F: DESCRIZIONE DELL'AZIONE. F.l- Modalita organizzative, gestione operativa e calendario dell'intervento. (Max 200 righe):

SEZIONE F: DESCRIZIONE DELL'AZIONE. F.l- Modalita organizzative, gestione operativa e calendario dell'intervento. (Max 200 righe): SEZIONE F: DESCRIZIONE DELL'AZIONE Project Management e Information Technology Infrastructure Library (ITIL V3 F.l- Modalita organizzative, gestione operativa e calendario dell'intervento. (Max 200 righe):

Dettagli

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

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

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

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

Dettagli

Analisi per tutti. Panoramica. Considerazioni principali. Business Analytics Scheda tecnica. Software per analisi

Analisi per tutti. Panoramica. Considerazioni principali. Business Analytics Scheda tecnica. Software per analisi Analisi per tutti Considerazioni principali Soddisfare le esigenze di una vasta gamma di utenti con analisi semplici e avanzate Coinvolgere le persone giuste nei processi decisionali Consentire l'analisi

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Carta di servizi per il Protocollo Informatico

Carta di servizi per il Protocollo Informatico Carta di servizi per il Protocollo Informatico Codice progetto: Descrizione: PI-RM3 Implementazione del Protocollo informatico nell'ateneo Roma Tre Indice ARTICOLO 1 - SCOPO DEL CARTA DI SERVIZI...2 ARTICOLO

Dettagli

DAL PROBLEMA AL PROGRAMMA

DAL PROBLEMA AL PROGRAMMA 1. I PROBLEMI E LA LORO SOLUZIONE DAL PROBLEMA AL PROGRAMMA L'uomo, per affrontare gli innumerevoli problemi postigli dallo sviluppo della civiltà, si è avvalso della scienza e della tecnica, i cui destini

Dettagli

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

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

Dettagli

SISSI IN RETE. Quick Reference guide guida di riferimento rapido

SISSI IN RETE. Quick Reference guide guida di riferimento rapido SISSI IN RETE Quick Reference guide guida di riferimento rapido Indice generale Sissi in rete...3 Introduzione...3 Architettura Software...3 Installazione di SISSI in rete...3 Utilizzo di SISSI in Rete...4

Dettagli

SIASFi: il sistema ed il suo sviluppo

SIASFi: il sistema ed il suo sviluppo SIASFI: IL SISTEMA ED IL SUO SVILUPPO 187 SIASFi: il sistema ed il suo sviluppo Antonio Ronca Il progetto SIASFi nasce dall esperienza maturata da parte dell Archivio di Stato di Firenze nella gestione

Dettagli

BPEL: Business Process Execution Language

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

Dettagli

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

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

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

Permutazione degli elementi di una lista

Permutazione degli elementi di una lista Permutazione degli elementi di una lista Luca Padovani padovani@sti.uniurb.it Sommario Prendiamo spunto da un esercizio non banale per fare alcune riflessioni su un approccio strutturato alla risoluzione

Dettagli

Informatica per la comunicazione" - lezione 9 -

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

Dettagli

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

Dettagli

1. UPM (Unità di Project Management) Centro di Medicina Preventiva e Comunitaria - Azienda ULSS 20 Verona

1. UPM (Unità di Project Management) Centro di Medicina Preventiva e Comunitaria - Azienda ULSS 20 Verona PRINCIPI PROJECT MANAGEMENT PRINCIPI DI PROJECT MANAGEMENT Elisabetta Simeoni 1), Giovanni Serpelloni 2) 1. UPM (Unità di Project Management) Centro di Medicina Preventiva e Comunitaria - Azienda ULSS

Dettagli

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi A2_3 V2.0. Processi. Scelta dei processi adeguati

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi A2_3 V2.0. Processi. Scelta dei processi adeguati Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A2_3 V2.0 Processi Scelta dei processi adeguati Il contenuto del documento è liberamente utilizzabile dagli studenti,

Dettagli

CAPITOLO 3. Elementi fondamentali della struttura organizzativa

CAPITOLO 3. Elementi fondamentali della struttura organizzativa CAPITOLO 3 Elementi fondamentali della struttura organizzativa Agenda La struttura organizzativa Le esigenze informative Tipologia di strutture Struttura funzionale Struttura divisionale Struttura per

Dettagli

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

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

Dettagli

Il seguente documento, predisposto dalla Commissione strutture dell Ordine degli

Il seguente documento, predisposto dalla Commissione strutture dell Ordine degli Il seguente documento, predisposto dalla Commissione strutture dell Ordine degli ingegneri della Provincia Autonoma di Trento nell anno 2012, si propone quale traccia per la stesura del Certificato di

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

LA TEMATICA. Questa situazione si traduce facilmente: IDENTITY AND ACCESS MANAGEMENT: LA DEFINIZIONE DI UN MODELLO PROCEDURALE ED ORGANIZZATIVO CHE, SUPPORTATO DALLE INFRASTRUTTURE, SIA IN GRADO DI CREARE, GESTIRE ED UTILIZZARE LE IDENTITÀ DIGITALI SECONDO

Dettagli

HORIZON SQL CONFIGURAZIONE DI RETE

HORIZON SQL CONFIGURAZIONE DI RETE 1-1/9 HORIZON SQL CONFIGURAZIONE DI RETE 1 CARATTERISTICHE DI UN DATABASE SQL...1-2 Considerazioni generali... 1-2 Concetto di Server... 1-2 Concetto di Client... 1-2 Concetto di database SQL... 1-2 Vantaggi...

Dettagli

Anno di corso: 2004/2005. Istruzioni. Istruzioni per lo svolgimento dei progetti didattici. versione 1.1

Anno di corso: 2004/2005. Istruzioni. Istruzioni per lo svolgimento dei progetti didattici. versione 1.1 versione 1.1 per lo svolgimento dei progetti didattici Corso di Laboratorio di Programmazione II Prof. Luca Forlizzi Anno Accademico 2004-2005 GENERALITÀ...3 Scopo del documento...3 Struttura del documento...3

Dettagli

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

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

Dettagli

Metodologie di Analisi e Valutazione delle Posizioni e delle Prestazioni

Metodologie di Analisi e Valutazione delle Posizioni e delle Prestazioni HUMANWARE S.A.S. Via Tino Buazzelli, 51 00137 - Roma Tel.: +39 06 823861 Fax.:+39 06 233214866 Web: www.humanware.it Email: humanware@humanware.it Metodologie di Analisi e Valutazione delle Posizioni e

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

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

Dettagli

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL)

Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Integrazione di servizi: Enterprise Service Bus (ESB) e Business Process Execution Language (BPEL) Corso di Sistemi Distribuiti Stefano

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

L 8 maggio 2002 il Ministero

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

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

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

Dettagli

INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI

INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI INTRODUZIONE AGLI ALGORITMI Prima di riuscire a scrivere un programma, abbiamo bisogno di conoscere un metodo risolutivo, cioè un metodo che a partire dai dati di ingresso fornisce i risultati attesi.

Dettagli

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP Università degli Studi di Pisa Facoltà di Scienze Matematiche,Fisiche e Naturali Corso di Laurea in Informatica Michela Chiucini MIB PER IL CONTROLLO DELLO STATO DI UN SERVER

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

Architetture CISC e RISC

Architetture CISC e RISC FONDAMENTI DI INFORMATICA Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine Architetture CISC e RISC 2000 Pier Luca Montessoro (si veda la nota di copyright alla slide n.

Dettagli

Analisi dei requisiti e casi d uso

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

Dettagli

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

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

Dettagli

Introduzione al Project Management. AIPA Area Monitoraggio e Verifiche

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

Dettagli

tratto da Economia e Management delle Imprese (DiBernardo, Gandolfi, Tunisini) A cura di Tonino Pencarelli Linda Gabbianelli

tratto da Economia e Management delle Imprese (DiBernardo, Gandolfi, Tunisini) A cura di Tonino Pencarelli Linda Gabbianelli tratto da Economia e Management delle Imprese (DiBernardo, Gandolfi, Tunisini) A cura di Tonino Pencarelli Linda Gabbianelli Organizzazione come sistema Ambiente interno Missione strategica Sistema tecnico

Dettagli

Milano, Settembre 2009 BIOSS Consulting

Milano, Settembre 2009 BIOSS Consulting Milano, Settembre 2009 BIOSS Consulting Presentazione della società Agenda Chi siamo 3 Cosa facciamo 4-13 San Donato Milanese, 26 maggio 2008 Come lo facciamo 14-20 Case Studies 21-28 Prodotti utilizzati

Dettagli

Gara LOCO- Richiesta di chiarimenti

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

Dettagli

VALUTAZIONE DINAMICA DEL POTENZIALE DI APPRENDIMENTO IN UN BAMBINO CON DISTURBO DELLO SPETTRO AUTISTICO

VALUTAZIONE DINAMICA DEL POTENZIALE DI APPRENDIMENTO IN UN BAMBINO CON DISTURBO DELLO SPETTRO AUTISTICO Fondamenti teorici Vygotskji Zona di Sviluppo Prossimale Feuerstein VALUTAZIONE DINAMICA DEL POTENZIALE DI APPRENDIMENTO IN UN BAMBINO CON DISTURBO DELLO SPETTRO AUTISTICO Esperienza di Apprendimento Mediato

Dettagli

La gestione della sicurezza nei contratti di appalto

La gestione della sicurezza nei contratti di appalto Sicurezza La gestione della sicurezza nei contratti di appalto Con l'emanazione del D.Lgs. n. 81/2008 sono stati definiti gli obblighi inerenti alla sicurezza sul lavoro in caso di affidamento di lavori

Dettagli

Progetto BPR: Business Process Reengineering

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

Dettagli

Informatica Applicata

Informatica Applicata Ing. Irina Trubitsyna Concetti Introduttivi Programma del corso Obiettivi: Il corso di illustra i principi fondamentali della programmazione con riferimento al linguaggio C. In particolare privilegia gli

Dettagli

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

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

Dettagli

Dalla Mappatura dei Processi al Business Process Management

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

Dettagli

STS. Profilo della società

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

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

INFORMATIVA SUI COOKIE

INFORMATIVA SUI COOKIE INFORMATIVA SUI COOKIE I Cookie sono costituiti da porzioni di codice installate all'interno del browser che assistono il Titolare nell erogazione del servizio in base alle finalità descritte. Alcune delle

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

LAVORARE PER PROGETTI

LAVORARE PER PROGETTI LAVORARE PER PROGETTI Giampaolo Calori e Nicoletta Perego Eulogos Consulenti di Direzione 1. PREMESSA Ogni giorno le aziende devono confrontarsi con il mutamento continuo dell ambiente interno ed esterno

Dettagli

ORDINE DEGLI ARCHITETTI, P.,P., e C. DELLA PROVINCIA DI PISA

ORDINE DEGLI ARCHITETTI, P.,P., e C. DELLA PROVINCIA DI PISA ORDINE DEGLI ARCHITETTI, P.,P., e C. DELLA PROVINCIA DI PISA COMMISSIONE TASSAZIONE NOTULE FASI O "LIVELLI DI ELABORAZIONE E REDAZIONE DEL PROGETTO ESECUTIVO NEI LAVORI PRIVATI PREMESSA L'accertamento

Dettagli

Descrizioni VHDL Behavioral

Descrizioni VHDL Behavioral 1 Descrizioni VHDL Behavioral In questo capitolo vedremo come la struttura di un sistema digitale è descritto in VHDL utilizzando descrizioni di tipo comportamentale. Outline: process wait statements,

Dettagli

MEGA Process. Manuale introduttivo

MEGA Process. Manuale introduttivo MEGA Process Manuale introduttivo MEGA 2009 SP4 1ª edizione (giugno 2010) Le informazioni contenute nel presente documento possono essere modificate senza preavviso e non costituiscono in alcun modo un

Dettagli

Progetto Mappa CET Versione 1.0 del 08-12-2010

Progetto Mappa CET Versione 1.0 del 08-12-2010 Progetto Mappa CET Versione 1.0 del 08-12-2010 La capacità di godere richiede cultura, e la cultura equivale poi sempre alla capacità di godere. Thomas Mann 1 Oggetto Il progetto consiste nella creazione

Dettagli

Processi ITIL. In collaborazione con il nostro partner:

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

Dettagli

Cap.1 - L impresa come sistema

Cap.1 - L impresa come sistema Cap.1 - L impresa come sistema Indice: L impresa come sistema dinamico L impresa come sistema complesso e gerarchico La progettazione del sistema impresa Modelli organizzativi per la gestione Proprietà

Dettagli