Requirement Engineering. Enrico Giunchiglia

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Requirement Engineering. Enrico Giunchiglia"

Transcript

1 Requirement Engineering Enrico Giunchiglia

2 Requisiti Requisito: Ogni informazione (ottenuta in qualche modo) circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare può quindi variare da una descrizione astratta ed imprecisa del sistema, fino a una descrizione dettagliata e matematica dello stesso. Enrico Giunchiglia Ingegneria del Software II 2

3 Requirement Engineering Il Requirement Engineering è il processo secondo cui i requisiti del sistema sono evidenziati, analizzati e validati. Scopo del Requirement Engineering è la produzione di un documento (il requirement document) che definisca le funzionalità e i servizi offerti dal sistema da realizzare Tale documento deve pertanto dire che cosa (piuttosto che come) il sistema dovrebbe fare Enrico Giunchiglia Ingegneria del Software II 3

4 Il processo di Requirement Engineering Feasibility study Feasibility report Requirements elicitation and analysis System models Requirements specification User and system Requirements validation Requirements document Enrico Giunchiglia Ingegneria del Software II 4

5 Elicitazione dei Requisiti L Elicitazione dei requisiti è il processo di acquisizione di informazioni sul sistema da sviluppare. Tale processo può coinvolgere diverse persone (end-users, managers, programmatori, esperti dominio), ma può anche comportare l analisi della legislazione e/o di realizzazioni pre-esistenti. Le diverse persone coinvolte in tale processo rappresentano gli stakeholders. Enrico Giunchiglia Ingegneria del Software II 5

6 Problemi nell Analisi dei Requisiti Gli Stakeholders difficilmente hanno una chiara idea di quello che esattamente vogliono (soprattutto all inizio) Gli Stakeholders usano un loro linguaggio (molto spesso tipico del dominio) molte volte non noto all analista E facile che diversi stakeholders abbiano richieste diverse, e quindi pongano requisiti in conflitto I requisiti del sistema possono dipendere da fattori esterni al sistema stesso (esigenze derivate da motivi organizzativi aziendali, o politico/legislativi) I requisiti (così come gli stakeholder) possono cambiare durante la fase di analisi Enrico Giunchiglia Ingegneria del Software II 6

7 Il Processo di Analisi dei Requisiti Requirements validation Requirements definition and specification Process entry Domain understanding Prioritization Requirements collection Conflict resolution Classification Enrico Giunchiglia Ingegneria del Software II 7

8 Classificazione dei requisiti I requisiti si possono dividere (o classificare) in diversi modi, in base a diversi parametri, quali 1. Le caratteristiche descritte (funzionali o non) 2. La sorgente del requisito (i view points) 3. L oggetto descritto (sistema vs. modulo) Enrico Giunchiglia Ingegneria del Software II 8

9 Requisiti Funzionali e Non I Requisiti Funzionali (Functional Requirement) descrivono le funzionalità ed i servizi forniti dal sistema I Requisiti Non Funzionali (Non Functional Requirement) non sono collegati direttamente con le funzioni implementate dal sistema, ma piuttosto alle modalità operative, di gestione,. Definiscono vincoli sullo sviluppo del sistema Enrico Giunchiglia Ingegneria del Software II 9

10 Esempio: Bancomat Si consideri un sistema bancomat. Il servizio deve mettere a disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie... Enrico Giunchiglia Ingegneria del Software II 10

11 Esempio: Bancomat Si consideri un sistema bancomat. Il servizio deve mettere a disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie... Enrico Giunchiglia Ingegneria del Software II 11

12 Esempio: Bancomat Si consideri un sistema bancomat. Il servizio deve mettere a disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie... Enrico Giunchiglia Ingegneria del Software II 12

13 Tipi di Requisiti Non Funzionali Non-functional Product Organizational External Efficiency Reliability Portability Interoperability Ethical Usability Delivery Implementation Standards Legislative Performance Space Privacy Safety Enrico Giunchiglia Ingegneria del Software II 13

14 Altri tipi di requisiti: di Dominio Domain Requirements: derivano dal dominio in cui il sistema deve operare. Es.: La decelerazione del treno deve essere computata come D train = D control + D gradient dove D gradient dipende dal tipo di treno Il sistema deve garantire la privatezza delle informazioni trattate, ed in particolare deve essere garantito da intrusioni esterne Enrico Giunchiglia Ingegneria del Software II 14

15 Altri tipi di Requisiti: Utente User Requirements: descrizione astratta, non tecnica del sistema. Deve essere comprensibile agli utenti del sistema. Di solito, sono specificati in linguaggio naturale. Es. Il sistema permetterà all utente di inserire/modificare/cancellare nodi attraverso menu a finestra Enrico Giunchiglia Ingegneria del Software II 15

16 Risoluzione dei Conflitti Può accadere che si abbiano inconsistenze fra requisiti non funzionali di sistemi complessi, soprattutto quando le sorgenti sono diverse Es. Il sistema deve essere operativo e funzionante entro X mesi Il sistema deve garantire Y funzionalità vs Il sistema non deve costare più di Z Soluzione: rimozione di uno dei due requisiti Enrico Giunchiglia Ingegneria del Software II 16

17 Prioritizzazione Più frequentemente si hanno conflitti fra requisiti non funzionali. Es.: Al fine di minimizzare il consumo di energia, si deve minimizzare il numero di chip utilizzati preferendo quelli a basso consumo vs Si devono garantire tempi di risposta adeguati Soluzione: Prioritizzazione Enrico Giunchiglia Ingegneria del Software II 17

18 Validazione dei Requisiti Il documento prodotto alla fine dell analisi è: Corretto: La descrizione rappresenta fedelmente i vincoli indicati dall utente? Completo: La descrizione comprende tutte le funzioni ed i vincoli indicati dall'utente? Consistente: Ci sono incongruenze tra i requisiti? (vedi IEEE ) Enrico Giunchiglia Ingegneria del Software II 18

19 Specifica dei Requisiti Processo attraverso il quale i requisiti vengono rappresentati e strutturati in modo organico Tecniche diverse si adattano a diverse categorie di problemi. É importante quindi scegliere la tecnica di specifica più adatta al problema e/o dominio Le tecniche si suddividono rispetto al grado di formalità linguaggio usato rispetto a cosa descrivono del sistema (il loro stile) Enrico Giunchiglia Ingegneria del Software II 19

20 Verifica/Validazione dei Requisiti Al fine di verificare una specifica, vi sono due possibilità: 1. Analisi delle proprietà del sistema, deducendole dalla specifica 2. Osservazione del comportamento dinamico del sistema: 1. Simulazione 2. Prototipazione Enrico Giunchiglia Ingegneria del Software II 20

21 Il Requirement Document Documento ufficiale risultato del Requirement Engineering Process Stabilisce che cosa il sistema deve fare, piuttosto che come si deve fare Usato sia in fase di sviluppo che di validazione/verifica del sistema Enrico Giunchiglia Ingegneria del Software II 21

22 IEEE Lo standard IEEE è espressamente dedicato al Software Requirements Specification (SRS). Il punto di partenza è costituito dalla definizione di otto attributi di qualità cui deve rispondere un SRS. Questi sono 1. Non ambiguità 2. Correttezza 3. Completezza 4. Verificabilità 5. Consistenza 6. Modificabilità 7. Tracciabilità 8. Priorità Enrico Giunchiglia Ingegneria del Software II 22

23 IEEE Std NON AMBIGUO An SRS is unambiguous if and only if every requirement stated therein has only one interpretation. As a minimum, this requires that each characteristic of the final product is described using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term must be included in a glossary where its meaning is made more specific. Ogni requisito ha una sola interpretazione possibile, sia per chi lo definisce ( chi scrive ), sia per chi lo usa ( chi legge ). Enrico Giunchiglia Ingegneria del Software II 23

24 IEEE Std CORRETTO An SRS is correct if and only if every requirement stated therein is one that the software shall meet. Ogni requisito rappresenta fedelmente nel sistema finale qualcosa che è stato richiesto Da questa definizione segue che: Non può esistere nessun tool o procedura che verifica la correttezza fino a quando il sistema non è implementato E possibile verificare la correttezza delle specifiche rispetto ad altre specifiche, ad esempio più astratte Enrico Giunchiglia Ingegneria del Software II 24

25 IEEE Std COMPLETO An SRS is complete if it posses the following qualities: 1. Inclusion of all significant, whether relating to functionality, perfomance, design constraints, attributes or external interfaces. 2. Definition of the responses of the software to all reliable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to valid and invalid input values. 3. Full labelling and referencing of all figures, tables, and diagrams in the SRS and definition of all terms and units of the measure. Any SRS that uses the phrase TBD... is not comple. If it is ncessary, it should be accompanied by: A description of the conditions causing the TBD (for example, why an answer is not known) so that the situation can be solved. A description of what must be done to eliminate the TBD. Contiene i requisiti di tutte le funzionalità del sistema, e specifica, per tutte le possibili classi di input, la risposta del sistema. La completezza è spesso ottenibile solo incrementalmente, dopo raffinamenti successivi. Enrico Giunchiglia Ingegneria del Software II 25

26 IEEE Std VERIFICABILE An SRS is verifiable if and only if every requirement stated therein is verifiable. A requirement is verifiable if and only if there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement. If a method cannot be devised to determine whether the software meets a particular requirement then that requirement has to be removed or revised. Ogni requisito deve essere chiaro. Se un requisito non è esprimibile in termini verificabili nel momento in cui l SRS viene definito, dovrebbe essere definito un momento del ciclo di vita del software entro cui il requisito deve essere presentato in una forma verificabile Enrico Giunchiglia Ingegneria del Software II 26

27 IEEE Std CONSISTENTE Consistency refers to internal consistency. An SRS is consistent if and only if no set of individual described in it conflict. There are three types of likely conflicts in an SRS: two or more might describe the same real world object but use different terms for that objects. the specified characteristics of the real world object might conflict. there might be a logical or temporal conflict between two specified actions. non esistono requisiti che non sono consistenti con altri Enrico Giunchiglia Ingegneria del Software II 27

28 IEEE Std MODIFICABILE An SRS is modifiable if and only if its structure and style are such that any necessary changes to the can be made easily, completely and consistently. Modifiability generally requires an SRS to: have a coerent and easy-to-use organization, with a table of contents, an index, and explicit cross-referencing; not to be redundant. Whenever redundancy is necessary, the SRS should include explicit cross-references to make it modifiable. Express each requirement separately, rather than intermixed with other. Enrico Giunchiglia Ingegneria del Software II 28

29 IEEE Std TRACCIABILE An SRS is traceable if the origin of each of its is clear and if it facilitates the referencing of the requirement in future development or enhancement of the documentation. Two types of traceability are recommented: 1. Backward Traceability: depends upon each requirement explicitly referencing its source in previous documents. 2. Forward Traceability: depends upon each requirement in the SRS having a unique name or reference number. Ogni requisito deve essere identificabile univocamente (FT). Quando un requisito A nell SRS deriva da un altro requisito B, deve essere specificata la dipendenza di A da B (BT). Enrico Giunchiglia Ingegneria del Software II 29

30 IEEE Std PRIORITA An SRS is ranked for importance and/or stability if each requirement in it has an identifier to indicate either the importance or stability of that particular requirement. Typically, all of the that relate to a software product are not equally important. Some may be essential, while others may be desiderable. Each requirement in the SRS should be identified to make these differences clear and explicit Enrico Giunchiglia Ingegneria del Software II 30

31 Struttura del Requirements Document (IEEE/ANSI ) 1. Introduzione 1. Obiettivo del Requirement Document 2. Obiettivo del prodotto 3. Definizioni, acronimi, abbreviazioni 4. Riferimenti 5. Struttura del documento 2. Descrizione Generale 1. Descrizione del prodotto dai diversi punti di vista 2. Funzionalità del prodotto 3. Caratteristiche utente 4. Vincoli sul prodotto 3. I Requisiti (funzionali, non-funzionali, lato utente ) 4. Appendici 5. Indice Enrico Giunchiglia Ingegneria del Software II 31

32 Struttura del Requirements Document (I. Sommerville) 1. Glossario: Definisce i termini tecnici utilizzati 2. Modelli del sistema: Definisce i modelli mostrando i componenti del sistema e le loro relazioni 3. Definizione dei requisiti funzionali: Descrive i servizi forniti 4. Definizione requisiti non funzionali: Definisce i vincoli sul sistema ed il processo di sviluppo 5. Evoluzione del sistema: Definisce le assunzioni principali su cui si basa il sistema e le modifiche future 6. Specifica dei requisiti: Specifica dettagliata dei requisiti funzionali 7. Appendici: Descrizione dettagliata collegata all applicazione da sviluppare. (Es. piattaforma hardware da usare, schema della base dei dati) 8. Indice Enrico Giunchiglia Ingegneria del Software II 32

Specifica dei requisiti

Specifica dei requisiti Specifica dei requisiti Contenuto: Cosa sono i requisiti Specifica col metodo classico Standard IEEE 830-1998 Cenni su altri standard 1 Cosa sono i requisiti Con la parola requisito si intende una caratteristica

Dettagli

Requirement Engineering. Enrico Giunchiglia

Requirement Engineering. Enrico Giunchiglia Requirement Engineering Enrico Giunchiglia Requisiti Requisito: Ogni informazione (ottenuta in qualche modo) circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare

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

TNCguide OEM Informativa sull introduzione di documentazione aggiuntiva nella TNCguide

TNCguide OEM Informativa sull introduzione di documentazione aggiuntiva nella TNCguide Newsletter Application 4/2007 OEM Informativa sull introduzione di documentazione aggiuntiva nella APPLICABILITÀ: CONTROLLO NUMERICO itnc 530 DA VERSIONE SOFTWARE 340 49x-03 REQUISITI HARDWARE: MC 420

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

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

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

Ingegneria del Software Testing. Corso di Ingegneria del Software Anno Accademico 2012/2013

Ingegneria del Software Testing. Corso di Ingegneria del Software Anno Accademico 2012/2013 Ingegneria del Software Testing Corso di Ingegneria del Software Anno Accademico 2012/2013 1 Definizione IEEE Software testing is the process of analyzing a software item to detect the differences between

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Ingegneria dei Requisiti Outline Ingegneria dei requisiti Tipologie i di Requisiti i i Attività per la raccolta dei requisiti Documento di Analisi dei requisiti Software Lifecycle Activities Requirements

Dettagli

Manutenzione del software

Manutenzione del software del software Generalità Leggi dell evoluzione del software Classi di manutenzione Legacy systems Modelli di processo per la manutenzione 1 Generalità La manutenzione del software è il processo di modifica

Dettagli

4. Requisiti del Software

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

Dettagli

Il Processo di Testing

Il Processo di Testing Il Processo di Testing I deliverable del processo di testing Il testing è un processo; L'esigenza di definire modelli di riferimento a partire dai quali istanziare tali processi; Un modo per fissare riferimenti

Dettagli

ESPERIENZE DI ESECUZIONE DI GAP ANALYSIS E RELATIVI PIANI DI ADEGUAMENTO ALLA ISO 26262 9 Automotive Software Workshop. Ernesto Viale 1 Dicembre 2011

ESPERIENZE DI ESECUZIONE DI GAP ANALYSIS E RELATIVI PIANI DI ADEGUAMENTO ALLA ISO 26262 9 Automotive Software Workshop. Ernesto Viale 1 Dicembre 2011 ESPERIENZE DI ESECUZIONE DI GAP ANALYSIS E RELATIVI PIANI DI ADEGUAMENTO ALLA ISO 26262 9 Automotive Software Workshop Ernesto Viale 1 Dicembre 2011 Skytechnology srl Skytechnology è una società di ingegneria,

Dettagli

Ingegneria del Software T. 2. Analisi orientata agli oggetti

Ingegneria del Software T. 2. Analisi orientata agli oggetti Ingegneria del Software T 2. Analisi orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare

Dettagli

Sezione 1 / Section 1. Elementi d identità: il marchio Elements of identity: the logo

Sezione 1 / Section 1. Elementi d identità: il marchio Elements of identity: the logo Sezione 1 / Section 1 2 Elementi d identità: il marchio Elements of identity: the logo Elements of identity: the logo Indice 2.01 Elementi d identità 2.02 Versioni declinabili 2.03 Versioni A e A1, a colori

Dettagli

Metodologie di progettazione

Metodologie di progettazione Metodologie di progettazione 1 Metodologie di progettazione Una procedura per progettare un sistema Il flusso di progettazione può essere parzialmente o totalmente automatizzato. Un insieme di tool possono

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2.

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2. Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Il processo di ingegneria dei requisiti (requirements engineering) varia in base al dominio applicativo, alle persone coinvolte ed all'organizzazione che sviluppa il sistema software Si può però individuare

Dettagli

13-03-2013. Introduzione al Semantic Web Linguaggi per la rappresentazione di ontologie. L idea del Semantic Web.

13-03-2013. Introduzione al Semantic Web Linguaggi per la rappresentazione di ontologie. L idea del Semantic Web. Corso di Ontologie e Semantic Web Linguaggi per la rappresentazione di ontologie Prof. Alfio Ferrara, Prof. Stefano Montanelli Definizioni di Semantic Web Rilievi critici Un esempio Tecnologie e linguaggi

Dettagli

no. SIC04053.03 Rev. 00 Dated 2008.10.02

no. SIC04053.03 Rev. 00 Dated 2008.10.02 TECHNICAL REPORT RAPPORTO TECNICO no. SIC04053.03 Rev. 00 Dated 2008.10.02 This technical report may only be quoted in full. Any use for advertising purposes must be granted in writing. This report is

Dettagli

e-privacy 2012 Open data e tutela giuridica dei dati personali

e-privacy 2012 Open data e tutela giuridica dei dati personali e-privacy 2012 Open data e tutela giuridica dei dati personali Milano, 22 giugno 2012 Prof. Avv. Alessandro Mantelero Politecnico di Torino IV Facoltà I. Informazione pubblica ed informazioni personali

Dettagli

Stabilire cosa richiede il cliente ad un prodotto software (Non stabilire come il prodotto verrà costruito)

Stabilire cosa richiede il cliente ad un prodotto software (Non stabilire come il prodotto verrà costruito) Obiettivi Scrivere (e leggere) i requisiti Cosa sono i requisiti di un prodotto software? Il processo di stesura dei requisiti Classificazione dei requisiti Notazioni per i requisiti La stesura dei requisiti

Dettagli

Classification of Financial Instrument(CFI)] quotazione si /no indicatore eventuale della quotazione

Classification of Financial Instrument(CFI)] quotazione si /no indicatore eventuale della quotazione Allegato 2 TRACCIATO DATI PER ANAGRAFICHE TITOLI INTERMEDIARI Per uniformare l invio delle informazioni sui titoli trattati presso gli internalizzatori sistematici si propone l invio di un file in formato

Dettagli

Individuazione e classificazione dei rifiuti pericolosi

Individuazione e classificazione dei rifiuti pericolosi Individuazione e classificazione dei rifiuti pericolosi Paolo Pipere Responsabile Servizio Ambiente ed Ecosostenibilità Camera di Commercio di Milano Classificazione dei rifiuti I criteri di classificazione

Dettagli

Laboratorio di Amministrazione di Sistema (CT0157) parte A : domande a risposta multipla

Laboratorio di Amministrazione di Sistema (CT0157) parte A : domande a risposta multipla Laboratorio di Amministrazione di Sistema (CT0157) parte A : domande a risposta multipla 1. Which are three reasons a company may choose Linux over Windows as an operating system? (Choose three.)? a) It

Dettagli

REGISTRATION GUIDE TO RESHELL SOFTWARE

REGISTRATION GUIDE TO RESHELL SOFTWARE REGISTRATION GUIDE TO RESHELL SOFTWARE INDEX: 1. GENERAL INFORMATION 2. REGISTRATION GUIDE 1. GENERAL INFORMATION This guide contains the correct procedure for entering the software page http://software.roenest.com/

Dettagli

Pubblicazioni COBIT 5

Pubblicazioni COBIT 5 Pubblicazioni COBIT 5 Marco Salvato CISA, CISM, CGEIT, CRISC, COBIT 5 Foundation, COBIT 5 Trainer 1 SPONSOR DELL EVENTO SPONSOR DI ISACA VENICE CHAPTER CON IL PATROCINIO DI 2 La famiglia COBIT 5 3 Aprile

Dettagli

Obiettivi. Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti UML Use Case Esercizi

Obiettivi. Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti UML Use Case Esercizi Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi Obiettivi Nelle lezioni precedenti abbiamo modellato il dominio business e i dati L obiettivo

Dettagli

5. Requisiti del Software II

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

Dettagli

PMBOK Guide 3 rd Edition 2004

PMBOK Guide 3 rd Edition 2004 PMBOK Guide 3 rd Edition 2004 Un modello di riferimento per la gestione progetti a cura di Tiziano Villa, PMP febbraio 2006 PMI, PMP, CAPM, PMBOK, PgMP SM, OPM3 are either marks or registered marks of

Dettagli

ESI International. Project Management & Business Analysis Solutions. www.esi-italy.it

ESI International. Project Management & Business Analysis Solutions. www.esi-italy.it ESI International Project Management & Business Analysis Solutions www.esi-italy.it Chi siamo Leader globali nei servizi di PERFORMANCE IMPROVEMENT in: Project Management Business Analysis Agile Project

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

LabMecFit. versione beta. by S.Frasca Dipartimento di Fisica Università Sapienza Roma

LabMecFit. versione beta. by S.Frasca Dipartimento di Fisica Università Sapienza Roma LabMecFit versione beta by S.Frasca Dipartimento di Fisica Università Sapienza Roma LabMecFit è un programma che permette di elaborare i dati prodotti da DataStudio. I dati devono essere salvati da DataStudio

Dettagli

1. Domanda di certificazione da riportare su carta intestata del fabbricante che richiede la certificazione / Certification request To report on

1. Domanda di certificazione da riportare su carta intestata del fabbricante che richiede la certificazione / Certification request To report on 1. Domanda di certificazione da riportare su carta intestata del fabbricante che richiede la certificazione / Certification request To report on LETTERHEAD PAPER of the applicant 2. Elenco documenti che

Dettagli

Introduzione Kerberos. Orazio Battaglia

Introduzione Kerberos. Orazio Battaglia Orazio Battaglia Il protocollo Kerberos è stato sviluppato dal MIT (Massachusetts Institute of Tecnology) Iniziato a sviluppare negli anni 80 è stato rilasciato come Open Source nel 1987 ed è diventato

Dettagli

LABORATORIO CHIMICO CAMERA DI COMMERCIO TORINO

LABORATORIO CHIMICO CAMERA DI COMMERCIO TORINO LABORATORIO CHIMICO CAMERA DI COMMERCIO TORINO Azienda Speciale della Camera di commercio di Torino clelia.lombardi@lab-to.camcom.it Criteri microbiologici nei processi produttivi della ristorazione: verifica

Dettagli

Misurare gli Open Source Software (OSS) e la Qualità di Prodotto

Misurare gli Open Source Software (OSS) e la Qualità di Prodotto 1 Forum Industria Italiana del Software Libero LUISS ilabs Roma, 8 Maggio 2015 Misurare gli Open Source Software (OSS) e la Qualità di Prodotto Luigi Buglione GUFPI-ISMA Gruppo Utenti Function Point Italia

Dettagli

Estendere Lean e Operational Excellence a tutta la Supply Chain

Estendere Lean e Operational Excellence a tutta la Supply Chain Estendere Lean e Operational Excellence a tutta la Supply Chain Prof. Alberto Portioli Staudacher www.lean-excellence.it Dipartimento Ing. Gestionale Politecnico di Milano alberto.portioli@polimi.it Lean

Dettagli

Famiglie di tabelle fatti

Famiglie di tabelle fatti aprile 2012 1 Finora ci siamo concentrati soprattutto sulla costruzione di semplici schemi dimensionali costituiti da una singola tabella fatti circondata da un insieme di tabelle dimensione In realtà,

Dettagli

ESERCITAZIONE. Francesco Poggi fpoggi@cs.unibo.it A.A. 2014-2015

ESERCITAZIONE. Francesco Poggi fpoggi@cs.unibo.it A.A. 2014-2015 ESERCITAZIONE Francesco Poggi fpoggi@cs.unibo.it A.A. 2014-2015 Premessa As always, there is never a correct solution to any modelling problem. It s more that some models are more precise, and more informative,

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

Riccardo Sponza Technical Evangelism Manager Microsoft Italia

Riccardo Sponza Technical Evangelism Manager Microsoft Italia Riccardo Sponza Technical Evangelism Manager Microsoft Italia SOA/EDA Composite Apps Software + Services Esercizio EAI Integrazione Punto-a-Punto Web services Consolidamento dell Infrastruttira Razionalizzazione

Dettagli

The Best Practices Book Version: 2.5

The Best Practices Book Version: 2.5 The Best Practices Book Version: 2.5 The Best Practices Book (2.5) This work is licensed under the Attribution-Share Alike 3.0 Unported license (http://creativecommons.org/ licenses/by-sa/3.0/). You are

Dettagli

ISO 9001:2015. Ing. Massimo Tuccoli. Genova, 27 Febbraio 2015

ISO 9001:2015. Ing. Massimo Tuccoli. Genova, 27 Febbraio 2015 ISO 9001:2015. Cosa cambia? Innovazioni e modifiche Ing. Massimo Tuccoli Genova, 27 Febbraio 2015 1 Il percorso di aggiornamento Le principali novità 2 1987 1994 2000 2008 2015 Dalla prima edizione all

Dettagli

Domain- Driven Design Giovedì, 21 giugno 2012 Speaker: Manuel Scapolan

Domain- Driven Design Giovedì, 21 giugno 2012 Speaker: Manuel Scapolan Domain- Dri ven Design Giovedì, 21 giugno 2012 Speaker: Manuel Scapolan Domain Driven Design E un insieme di principi che ci aiutano a non fallire nel processo di sviluppo di un software * * considerando

Dettagli

ELTeach. Ottmizza lia preparazione pedagogica dei docenti all insegnamento dell inglese in inglese

ELTeach. Ottmizza lia preparazione pedagogica dei docenti all insegnamento dell inglese in inglese ELTeach Ottmizza lia preparazione pedagogica dei docenti all insegnamento dell inglese in inglese Porta a risultati quantificabili e genera dati non ricavabili dalle sessioni di formazione faccia a faccia

Dettagli

PROGRAMMA DI LINGUA INGLESE

PROGRAMMA DI LINGUA INGLESE PROGRAMMA DI LINGUA INGLESE CLASSE IG ANNO SCOLASTICO 2014/2015 Prof.ssa Rossella Mariani Testo in adozione: THINK ENGLISH 1 STUDENT S BOOK, corredato da un fascicoletto introduttivo al corso, LANGUAGE

Dettagli

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

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

Dettagli

We take care of your buildings

We take care of your buildings We take care of your buildings Che cos è il Building Management Il Building Management è una disciplina di derivazione anglosassone, che individua un edificio come un entità che necessita di un insieme

Dettagli

COMUNITA TERAPEUTICA IL FARO

COMUNITA TERAPEUTICA IL FARO COMUNITA TERAPEUTICA IL FARO Ristrutturazione per danni provocati dal sisma e adeguamento nuove normative Presentazione al 31.10.2010 STATO DI FATTO PRIMA DEL SISMA DI APRILE 2009 CRITICITA CRITICITA Spazi

Dettagli

Paradigma object-oriented

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

Dettagli

IMPLEMENTAZIONE DEI TAG SOFTWARE NEI PRODOTTI ADOBE NOTE TECNICHE

IMPLEMENTAZIONE DEI TAG SOFTWARE NEI PRODOTTI ADOBE NOTE TECNICHE IMPLEMENTAZIONE DEI TAG SOFTWARE NEI PRODOTTI ADOBE NOTE TECNICHE 2011 Adobe Systems Incorporated. All rights reserved. Software Tag Implementation in Adobe Products Tech Note Adobe, the Adobe logo, and

Dettagli

Introduzione all ambiente di sviluppo

Introduzione all ambiente di sviluppo Laboratorio II Raffaella Brighi, a.a. 2005/06 Corso di Laboratorio II. A.A. 2006-07 CdL Operatore Informatico Giuridico. Introduzione all ambiente di sviluppo Raffaella Brighi, a.a. 2005/06 Corso di Laboratorio

Dettagli

Gruppo di lavoro 1 Metadati e RNDT. Incontro del 22 luglio 2014

Gruppo di lavoro 1 Metadati e RNDT. Incontro del 22 luglio 2014 Gruppo di lavoro 1 Metadati e RNDT Incontro del 1 Piano di lavoro 1. Condivisione nuova versione guide operative RNDT 2. Revisione regole tecniche RNDT (allegati 1 e 2 del Decreto 10 novembre 2011) a)

Dettagli

Prova finale di Ingegneria del software

Prova finale di Ingegneria del software Prova finale di Ingegneria del software Scaglione: Prof. San Pietro Andrea Romanoni: Francesco Visin: andrea.romanoni@polimi.it francesco.visin@polimi.it Italiano 2 Scaglioni di voto Scaglioni di voto

Dettagli

ELCART. Manuale di istruzioni/scheda tecnica SPECIFICATION

ELCART. Manuale di istruzioni/scheda tecnica SPECIFICATION PAGINA 1 DI 7 SPECIFICATION Customer : ELCART Applied To : Product Name : Piezo Buzzer Model Name : : Compliance with ROHS PAGINA 2 DI 7 2/7 CONTENTS 1. Scope 2. General 3. Maximum Rating 4. Electrical

Dettagli

Auditorium dell'assessorato Regionale Territorio e Ambiente

Auditorium dell'assessorato Regionale Territorio e Ambiente Auditorium dell'assessorato Regionale Territorio e Ambiente Università degli Studi di Palermo Prof. Gianfranco Rizzo Energy Manager dell Ateneo di Palermo Plan Do Check Act (PDCA) process. This cyclic

Dettagli

CERTIFICATO DI CONFORMITA' Allegato a Documento giustificativo ai sensi dell'art. 29, 1 del Reg CE 834/07 S'ATRA SARDIGNA SOC. COOP. A.R.L.

CERTIFICATO DI CONFORMITA' Allegato a Documento giustificativo ai sensi dell'art. 29, 1 del Reg CE 834/07 S'ATRA SARDIGNA SOC. COOP. A.R.L. Numero identificativo documento giustificativo N reference of Documentary evidence 2014/00011 Numero identificativo N Reference 00104 del 17/09/2014 E' CONFORME AI REQUISITI DEL PRODOTTO BIOLOGICO Reg.

Dettagli

Ingegneria del Software

Ingegneria del Software Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A1_1 V2.2 Ingegneria del Software Il contesto industriale del software Il contenuto del documento è liberamente utilizzabile

Dettagli

portfolio www.zero3studio.it info@zero3studio.it

portfolio www.zero3studio.it info@zero3studio.it portfolio www.zero3studio.it info@zero3studio.it comunicazione visiva, progettazione grafica e sviluppo web visual communication, graphic design and web development www.zero3studio.it info@zero3studio.it

Dettagli

Gli aspetti innovativi del Draft International Standard (DIS) ISO 9001:2015

Gli aspetti innovativi del Draft International Standard (DIS) ISO 9001:2015 Gli aspetti innovativi del Draft International Standard (DIS) ISO 9001:2015 I requisiti per la gestione del rischio presenti nel DIS della nuova ISO 9001:2015 Alessandra Peverini Perugia 9/09/2014 ISO

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

brand implementation

brand implementation brand implementation brand implementation Underline expertise in reliable project management reflects the skills of its personnel. We know how to accomplish projects at an international level and these

Dettagli

La qualità del software OS

La qualità del software OS Università degli Studi dell Insubria Dipartimento di Informatica e Comunicazione La qualità del software OS Luigi Lavazza luigi.lavazza@uninsubria.it DICOM Università dell'insubria - Varese & CEFRIEL Titoli

Dettagli

Unbounce Optimization

Unbounce Optimization Unbounce Optimization Alberto Mucignat Milano, 01 dicembre 2015 Doralab - Experience Design Company User Intelligence User Experience Design Business value 2 3 Full stack UX design Architettura dell informazione

Dettagli

Painting with the palette knife

Painting with the palette knife T h e O r i g i n a l P a i n t i n g K n i v e s Dipingere con la spatola Painting with the palette knife Made in Italy I t a l i a n M a n u f a c t u r e r La ditta RGM prende il nome dal fondatore

Dettagli

ATTESTATO DELL ATTIVITÀ DI VOLONTARIATO CERTIFICATE OF VOLUNTARY ACTIVITIES

ATTESTATO DELL ATTIVITÀ DI VOLONTARIATO CERTIFICATE OF VOLUNTARY ACTIVITIES ASSOCIAZIONE CONSORTI DIPENDENTI MINISTERO AFFARI ESTERI ATTESTATO DELL ATTIVITÀ DI VOLONTARIATO CERTIFICATE OF VOLUNTARY ACTIVITIES ASSOCIAZIONE CONSORT I DIPENDENTI MINISTE RO AFFARI ESTER I ATTESTATO

Dettagli

Scuola Primaria FINALE SQ. - 14/15 ESERCIZIO 1

Scuola Primaria FINALE SQ. - 14/15 ESERCIZIO 1 ESERCIZIO 1 Si ricordi che una regola di deduzione è un termine che ha la struttura: regola(,,). Tale termine indica una regola di nome che consente di dedurre

Dettagli

Le cellule staminali dell embrione: cosa possono fare Embryonic stem cells are exciting because they can make all the different types of cell in the

Le cellule staminali dell embrione: cosa possono fare Embryonic stem cells are exciting because they can make all the different types of cell in the 1 2 3 Le cellule staminali dell embrione: cosa possono fare Embryonic stem cells are exciting because they can make all the different types of cell in the body scientists say these cells are pluripotent.

Dettagli

Verifica del codice con Interpretazione Astratta

Verifica del codice con Interpretazione Astratta Verifica del codice con Interpretazione Astratta Daniele Grasso grasso@dsi.unifi.it grasso.dan@gmail.com Università di Firenze, D.S.I., Firenze, Italy December 15, 2009 D.Grasso (Università di Firenze)

Dettagli

GstarCAD 2010 Features

GstarCAD 2010 Features GstarCAD 2010 Features Unrivaled Compatibility with AutoCAD-Without data loss&re-learning cost Support AutoCAD R2.5~2010 GstarCAD 2010 uses the latest ODA library and can open AutoCAD R2.5~2010 DWG file.

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

Dr Mila Milani. Comparatives and Superlatives

Dr Mila Milani. Comparatives and Superlatives Dr Mila Milani Comparatives and Superlatives Comparatives are particular forms of some adjectives and adverbs, used when making a comparison between two elements: Learning Spanish is easier than learning

Dettagli

up date basic medium plus UPDATE

up date basic medium plus UPDATE up date basic medium plus UPDATE Se si potesse racchiudere il senso del XXI secolo in una parola, questa sarebbe AGGIORNAMENTO, continuo, costante, veloce. Con UpDate abbiamo connesso questa parola all

Dettagli

υ Verifica della completezza di una definizione υ Identificazione dei requisiti del software υ Identificazione degli obiettivi del progetto

υ Verifica della completezza di una definizione υ Identificazione dei requisiti del software υ Identificazione degli obiettivi del progetto La Norma ISO/IEC 9126 Luigi Lavazza, 2001 ISO/IEC 9126 1 υ Standard di valutazione della qualità di prodotti software dell International Organisation for Standardisation e dell International Electrotechnical

Dettagli

Progettazione del Software. www.vincenzocalabro.it

Progettazione del Software. www.vincenzocalabro.it Progettazione del Software 1 Progettazione del Software Software Design = derivare soluzioni che soddisfino il documento dei requisiti Fasi del processo di progettazione Strategie di progettazione: approccio

Dettagli

Algoritmi e strutture di dati 2

Algoritmi e strutture di dati 2 Algoritmi e strutture di dati 2 Paola Vocca Lezione 2: Tecniche golose (greedy) Lezione1- Divide et impera 1 Progettazione di algoritmi greedy Tecniche di dimostrazione (progettazione) o Greedy algorithms

Dettagli

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

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

Dettagli

Il processo di ingegneria dei requisiti

Il processo di ingegneria dei requisiti Il processo di ingegneria dei requisiti Il processo di ingegneria dei requisiti (requirements engineering) varia in base al dominio applicativo, alle persone coinvolte ed all'organizzazione che sviluppa

Dettagli

Send message Transaction list. Transfer funds

Send message Transaction list. Transfer funds Query balance Machine supplies User interface Account holder Remote diagnostics Get transactions Account information System cost Stolen card Manager Reliability Customer database Message log Order statement

Dettagli

The Zachman Framework for Enterprise Architecture

The Zachman Framework for Enterprise Architecture The Zachman Framework for Enterprise Architecture Introduzione Una delle sfide più importanti che un impresa moderna deve affrontare è quella del cambiamento. Considerando la necessità di cambiamento dal

Dettagli

Società per la Biblioteca Circolante Programma Inglese Potenziato

Società per la Biblioteca Circolante Programma Inglese Potenziato Società per la Biblioteca Circolante Programma Inglese Potenziato STRUTTURE GRAMMATICALI VOCABOLI FUNZIONI COMUNICATIVE Presente del verbo be: tutte le forme Pronomi Personali Soggetto: tutte le forme

Dettagli

TEST REPORT INDICE - INDEX

TEST REPORT INDICE - INDEX Test Report Number: 10/11/2015 Sesto San Giovanni (MI) Data Emissione - Issuing date Luogo Emissione - Issuing place Verifica della conformità al capitolato prove di KIDS P.A. S.r.l secondo EN 12266-1:2012

Dettagli

4th International Conference in Software Engineering for Defence Applications SEDA 2015

4th International Conference in Software Engineering for Defence Applications SEDA 2015 me Ho CALL FOR PAPERS: 4th International Conference in Software Engineering for Defence Applications SEDA 2015 Software Engineering aims at modeling, managing and implementing software development products

Dettagli

Portale Materiali Grafiche Tamburini. Grafiche Tamburini Materials Portal

Portale Materiali Grafiche Tamburini. Grafiche Tamburini Materials Portal Portale Materiali Grafiche Tamburini Documentazione utente italiano pag. 2 Grafiche Tamburini Materials Portal English user guide page 6 pag. 1 Introduzione Il Portale Materiali è il Sistema Web di Grafiche

Dettagli

Il dossier di registrazione, il CSR e la notifica della classificazione

Il dossier di registrazione, il CSR e la notifica della classificazione Il dossier di registrazione, il CSR e la notifica della classificazione Raffaella Butera Servizio di Tossicologia IRCCS Fondazione Maugeri e Università degli Studi di Pavia raffaella.butera@unipv.it Esperienza

Dettagli

La struttura della ISO 26000. Antonio Astone 26 giugno 2007

La struttura della ISO 26000. Antonio Astone 26 giugno 2007 La struttura della ISO 26000 Antonio Astone 26 giugno 2007 Description of operational principles (1/2) Operational principles guide how organizations act. They include: Accountability an organization should

Dettagli

Terminologia per gli ipertesti sul web

Terminologia per gli ipertesti sul web Terminologia per gli ipertesti sul web browser: programma applicativo per navigare in rete page (pagina): singolo foglio di un ipertesto home-page: punto di ingresso di un sito web hotspot, hotword: porzione

Dettagli

Ingegneria del Software

Ingegneria del Software Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A1_3 V2.4 Ingegneria del Software Il corpus di conoscenze Il contenuto del documento è liberamente utilizzabile dagli

Dettagli

Librerie digitali. Introduzione. Cos è una libreria digitale?

Librerie digitali. Introduzione. Cos è una libreria digitale? Librerie digitali Introduzione Cos è una libreria digitale? William Arms "An informal definition of a digital library is a managed collection of information, with associated services, where the information

Dettagli

Piano di gestione della qualità

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

Dettagli

LO LH BUSREP. 1 2 3 Jp2. Jp1 BUSREP. Ripetitore di linea seriale RS 485 Manuale d installazione RS 485 Serial Line Repeater Instruction Manual

LO LH BUSREP. 1 2 3 Jp2. Jp1 BUSREP. Ripetitore di linea seriale RS 485 Manuale d installazione RS 485 Serial Line Repeater Instruction Manual Jp MS 4 LINEA 4 MS MS LINEA LINEA Tx4 Tx Tx Tx BUSREP S Jp Jp LINEA GND +,8 Jp4 BUSREP Ripetitore di linea seriale RS 485 Manuale d installazione RS 485 Serial Line Repeater Instruction Manual Edizione/Edition.

Dettagli

Documentazione degli studi clinici

Documentazione degli studi clinici Documentazione degli studi clinici Gestione e Coordinamento degli Studi Clinici nei Sarcomi 1 Corso ISG di Formazione per la Ricerca Clinica Manuela Monti Manuela Monti Clinical Research Coordinator Unità

Dettagli

Redazione Approvazione Autorizzazione all emissione Entrata in vigore. Il Direttore Generale 2015-07-16

Redazione Approvazione Autorizzazione all emissione Entrata in vigore. Il Direttore Generale 2015-07-16 Titolo/Title Elenco norme e documenti di riferimento per l'accreditamento degli Organismi di Verifica delle emissioni di gas ad effetto serra List of reference standards and documents for the accreditation

Dettagli

Il BACKUP è disponibile in http://www.dbgroup.unimo.it/sia/esercizio_21_novembre_2013/esercizio_21_novembre_2013.bak

Il BACKUP è disponibile in http://www.dbgroup.unimo.it/sia/esercizio_21_novembre_2013/esercizio_21_novembre_2013.bak ESEMPIO DELLE VENDITE: MISURE ED AGGREGABILITA E l esempio discusso nelle dispense è Dispense : http://www.dbgroup.unimo.it/sia/sia_2014_progettazionediundw_misure.pdf esteso e dettagliato. Il BACKUP è

Dettagli

Carlo Bestetti Consulente Tonino Ranieri - Schering Plough Workshop Predictive Maintenance & Calibration, Milano 14 dicembre 2006

Carlo Bestetti Consulente Tonino Ranieri - Schering Plough Workshop Predictive Maintenance & Calibration, Milano 14 dicembre 2006 Dai requisiti, alla convalida di software per la gestione della calibrazione e manutenzione Carlo Bestetti Consulente Tonino Ranieri - Schering Plough 1 Workshop Predictive Maintenance & Calibration, Milano

Dettagli

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it Progetto Struttura del documento di specifica dei requisiti, Casi d uso manuel.comparetti@iet.unipi.it 1 Documenti da produrre Il progetto deve comprendere i seguenti documenti: Documento di specifica

Dettagli

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Requisiti Software Requisiti software (software ): descrizione dei servizi che un sistema software deve fornire, insieme ai vincoli da rispettare sia in fase di sviluppo che durante la fase di operatività

Dettagli

CERTIFICATO DI CONFORMITA' Documento giustificativo ai sensi dell'art. 29, 1 del Reg CE 834/07

CERTIFICATO DI CONFORMITA' Documento giustificativo ai sensi dell'art. 29, 1 del Reg CE 834/07 AZIENDA AGRICOLA SAN DOMENICO DI RUBINO MICHELE & C. SNC VIA RUTIGLIANO, 12 CERTIFICATO DI CONFORMITA' IT BIO 006 P318 10.116 E' CONFORME AI REQUISITI DEL PRODOTTO BIOLOGICO Reg. CE 834/07 E CE 889/08

Dettagli