Schema del Corso. Requirements Engineering: Natural Language Requirements Elicitation, Specification and Quality Evaluation Part II

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Schema del Corso. Requirements Engineering: Natural Language Requirements Elicitation, Specification and Quality Evaluation Part II"

Transcript

1 Requirements Engineering: Natural Language Requirements Elicitation, Specification and Quality Evaluation Part II Giuseppe Lami Ph.D. System & Software Evaluation Centre Istituto di Scienza e Tecnologie dell Informazione CNR, Pisa Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA (USA) Tel Schema del Corso Software Qualità del Software Processo Software Software Project Management Ingegneria del Software Misurare la Qualità del Software Requisiti Software Requirements Engineering Elicitation dei Requisiti: Tecniche & Tools Specifica dei Requisiti: Tecniche & Tools Qualità dei Requisiti Esperienza con i Requisiti Software Test Finale 1

2 Impatto delle attività di RE Esistono molti studi che testimoniano come la causa dei maggiori problemi in un progetto software è collegabile ai requisiti I difetti software costano all economia USA 59,5 miliardi di $, lo 0,6% del PIL Uno studio dello Standish Group rivela che le principali cause di progetti in difficoltà sono: Carenza di coinvolgimento dell utente (12,8%),, requisiti incompleti (12,3%), requisiti che cambiano (11,8%) Uno studio dell ESI condotto su un campione di 3800 organizzazioni in 17 stati europei mostra come il 50% dei problemi è relativo all area della specifica dei requisiti Un recente studio (2002) su 12 aziende software UK mostra che i soli problemi dovuti ai requisiti rappresentano il 48% del totale Un studio di B. Bohem mostra che, dato 1$ il costo della soluzione di un errore nella fase di definizione dei requisiti, tale costo diventa 200 5$ nella fase di design, 10$ in quella di codifica, $ nel testing $ dopo la delivery 50 0 req. design coding testing after-del. Requirements Engineering (RE) Definizione: processo che include tutte le attività per creare e mantenere un documento di requisiti. Le attività di base del RE sono: Studio di fattibilità del sistema Elicitation e analisi dei requisiti Specifica e documentazione dei requisiti Validazione dei requisiti [Sommerville 2001] Definizione: processo che, a livello di progetto, raccoglie, documenta e gestisce i requisiti per l intera durata del progetto [Aurum, Wohlin 2005] 2

3 Requirements Engineering Principali fasi: Elicitation Studi di fattibilità Specifica modellizzazione Negoziazione Analisi di qualità Analisi dell impatto Prioritizzazione Change management Che cos è un requisito software A feature that the system must have or a constraint it must satisfy to be accepted by the client [Bruegge, Dutoit] 1) a condition or capability needed by a user to solve a problem or achieve an objective 2) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents, A documented representation of a condition or capability as in 1) or2). [IEEE ] 3

4 Classificazioni dei requisiti Funzionali: che cosa il sistema farà Non-funzionali: vincoli sui tipi di soluzioni che verranno sviluppate in conformità ai requisiti funzionali (es. accuratezza, performance, security, modificabilità, ) Goal level: relativi agli obiettivi di business Domain level: relativi all area del problema Product level: relativi al prodotto Design level: che cosa costruire Primari: ottenuti (attraverso l elicitation) dagli stakeholders Derivati: derivati da quelli primari Business vs. tecnici di prodotto vs. di processo: business needs vs. come le persone interagiranno con il sistema Basati sul ruolo: cliente, utente, sistema, security Requirements Engineering Key Points Impatto dei requisiti sul destino di un progetto Attività di base del requirements engineering Requisiti definizione e classificazione 4

5 Elicitation dei Requisiti Definizione: the process of seeking, uncovering, acquiring, and elaborating requirements for computer based systems [Zowghi 2005] Using systematic techniques to proactively identify and document customer and end-user needs [CMMI] Il Processo di Elicitation dei Requisiti Scopo: raccogliere, elaborare e tracciare le esigenze del cliente in evoluzione e i requisiti lungo tutto il ciclo di vita del prodotto e/o servizio in modo da stabilire una baseline di requisiti che serva come base per la definizione dei work product necessari. Risultati attesi: Comprendere il dominio applicativo (i.e. l ambiente dove il sistema opererà) Identificare le fonti (stakeholders, documenti sui sistemi attuali, processi di business, manuali, report, ); Selezionare tecniche, approcci e tool da usare Ottenere i requisiti e le richieste dal cliente e dagli altri stakeholder; Comprendere le aspettative del cliente Trovare un accordo sui requisiti Stabilire una baseline dei requisiti del cliente Gestire i cambiamenti ai requisiti del cliente Definire un meccanismo per le query del cliente WP in input: committment/agreement, change request, customer request, customer requirements WP in output: customer requirements, change control record, analysis report 5

6 Esiste una interpretazione comune? La descrizione del prodotto è corretta? 6

7 Tecniche e tool per l elicitation Interviste Questionari Introspezione Card sorting Brainstorming JAD (Joint Application Development) Requirements workshop Etnografia Prototipazione Approcci Goal-based Scenari/Use Case Viewpoint 7

8 Tecniche e tool per l elicitation (cont.) Interviste: Tecnica tradizionale Molte informazioni in breve tempo Efficacia dipendente dall abilità dell intervistatore Strutturate: Insiemi predeterminati di domande Criticità: quali domande, quando e a chi farle Pros: rigorose e efficaci Contra: limitazione all investigazione di nuove idee Non strutturate: Conversazioni informali dove l intervistatore controlla solo la direzione della discussione Rischio di escludere interi aspetti e di sovrabbondare di dettagli su altri Si adattano bene alla fase esplorativa Tool: Volere: fornisce template per le interviste [Robertson, Robertson (1999) Mastering the requirmeents process, Addison Wesley: UK] Tecniche e tool per l elicitation (cont.) Questionari Domande aperte o chiuse Criticità: glossario condiviso Formulare le domande per evitare il rischio di risposte ridondanti o troppo lunghe Pros: ottenere in breve tempo informazioni da diversi stakeholder Contra: limtazioni sulla profondità delle informazioni raccolte Utili anche come check-list per assicurare di considerare tutti i punti importanti Introspezione All analista viene richiesto di sviluppare i requisiti sulla base do ciò che egli crede gli utenti e gli altri stakeholders vogliono e hanno bisogno Meglio se usata come punto di partenza e insieme ad altre tecniche 8

9 Tecniche e tool per l elicitation (cont.) Card sorting Viene richiesto agli stakeholder di ordinare in gruppi sulla base della propiria comprensione un mazzo di carte sulle quali sono stati riportati i nomi di entità del dominio Si chiede il motivo dell ordinamento fatto Tutte le entità del dominio devo essere incluse nelle carte Necessità di conoscenza del dominio da parte di tutti gli attori coinvolti Tool CRC Brainstorming Meeting dove partecipano rappresentanti di tutti gli stakeholders Discussione informale dove si generano più idee possibile senza focalizzarsi su nessuna di esse e senza scendere nei dettagli Utile per produrre un iniziale misson statement per il progetto e il sistema da realizzare Libero e informale, aiuta a trovare soluzioni nuove e innovative Tecniche e tool per l elicitation (cont.) JAD (Joint Application Development) Meeting fra tutti gli stakeholders ma la discussione verte non solo sui problemi da risolvere ma anche sulle possibili soluzioni a quei problemi Decisioni possono essere prese rapidamente Sessioni strutturate con step, azioni e ruoli definiti Etnografia Studio delle persone nel proprio ambiente naturale. Prevede che l analista partecipi attivamente o passivamente alle normali attività degli utenti su un intervallo temporale ampio per raccogliere informazioni su come essi operano Utili per considerare fattori dipendenti dal contesto come l usabilità e le interazioni fra gli utenti finali Efficace quando il motivo di un nuovo sistema è il risultato di problemi con gli attuali processi e procedure 9

10 Tecniche e tool per l elicitation (cont.) Prototipazione Si forniscono agli stakeholder prototipi del sistema finale per raccogliere informazioni dettagliate e feedback di rilievo. Utile quando si sviluppano interfacce uomomacchina gli stakeholders non hanno familiarità con le soluzioni disponibili Si sviluppano nuovi sistemi per applicazioni del tutto nuove Gli stakoholder sono spinti ad avere un ruolo attivo nello sviluppo dei requisiti Rischio: affezionarsi a un prototipo e non voler andare avanti Approcci goal-based Gli obiettivi di alto livello (high-level goal) che rappresentano gli obiettivi per il sistema sono decomposti (usando le relazioni AND e OR) e elaborati (con domande come e perché ) in sotto-obiettivi che man mano vengono raffinati fino a quando i requisiti sono ottenuti Riesce a rappresentare relazioni dettagliate fra entità del dominio, requisiti e obiettivi del sistema) Rischio: propagazione fino nei requisiti di eventuali errori negli obiettivi di alto livello Tool: F3, KAOS meta- model, framework i* Tecniche e tool per l elicitation (cont.) Scenari / Use Case Molto usati in req. elicitation Sono narrazioni e descrizioni specifiche di processi attuali e futuri che includono azioni e interazioni fra il sistema e l utente Occorre raccogliere tutte lo possibili eccezioni a ciascuno step Tool e tecniche specifiche: CREWS l Ecritoire, The Inquiry Cycle, SBRE, Scenario Plus USE CASE # < the name is the goal as a short active verb phrase> Goal in Context <a longer statement of the goal in context if needed> Scope & Level <what system is being considered black box under design> <one of: Summary, Primary Task, Sub-function> Preconditions <what we expect is already the state of the world> Success End Condition <the state of the world upon successful completion> Failed End Condition <the state of the world if goal abandoned> Primary, Secondary Actors <a role name or description for the primary actor>. <other systems relied upon to accomplish use case> Trigger <the action upon the system that starts the use case> Description Step Action 1 <put here the steps of the scenario from trigger to goal delivery, and any cleanup after> 2 <...> 3 Extensions Step Branching Action 1a <condition causing branching> : <action or name of sub-use case> Sub-Variations Branching Action 1 <list of variations> 10

11 Tecniche e tool per l elicitation (cont.) View point Lo scopo è quello di modellare il dominio da diverse prospettive per sviluppare una descrizione completa consistente del sistema Un sistema può essere descritto in termini della sua operatività, interfacce, implementazione Contra: non permettono di rappresentare facilmente i requisiti non funzionali Troppi viewpoint portano ad una massa di dati non gestibile Tool: VORD (Viewpoint-oriented Requirements Definition) Tecniche vs. attività dell elicitation interviste JAD etnografia prototip. goal-based scenari comprendere il dominio X X X X X X identificare fonti di requisiti X X X X X analizzare gli stakeholder X X X X X X X selezionare tecniche e approcci X X viewpoint eliciting dei requisiti X X X X X X X 11

12 Tecniche complementari e altrenative interviste JAD etnografia prototip. goal-based scenari viewpoint interviste A A A C C C JAD A A C C C C etnografia A A C C A A prototip. A C C C C C goal-based C C C C C C scenari C C A C C A viewpoint C C A C C A Requirements Elicitation Key Points Definizione del processo di Elicitation dei requisiti Tecniche per l elicitation dei requisiti 12

13 Schema del Corso Software Qualità del Software Processo Software Software Project Management Ingegneria del Software Misurare la Qualità del Software Requisiti Software Requirements Engineering Elicitation dei Requisiti: Tecniche & Tools Specifica dei Requisiti: Tecniche & Tools Qualità dei Requisiti in Linguaggio Naturale Esperienza con i Requisiti Software Test Finale Specifica dei Requisiti La prima rappresentazione dei requisiti del cliente è sempre in linguaggio naturale perché per la loro realizzazione devono essere coinvolti diversi stakeholders. Il linguaggio naturale ha il vantaggio di essere comprensibile da tutti ma lo svantaggio di essere intrinsecamente ambiguo. Quando i requisiti necessitano di essere maggiormente dettagliati, possono essere rappresentati in modo più tecnico: Modelli di sistema (UML) Metodi formali Una recente indagine indica che 79% dei documenti di requisiti sono scritti in linguaggio naturale, 16% in linguaggio naturale strutturato e solo i 5% usando linguaggi formalizzati. [Mich 2002] 13

14 La qualità dei requisiti in linguaggio naturale Definiamo un modello di qualità formato dalle caratteristiche di qualità importanti per i requisiti: Correttezza Non ambiguità Completezza Consistenza Importanza Stabilità Verificabilità Modificabilità Tracciabilità Comprensibilità Fattibilità Livello di dettaglio adeguato Caratteristiche di qualità dei requisiti - Definizioni Correttezza: i requisiti che sono implementati devono riflettere il comportamento atteso. Le cose stabilite da un requisito devono essere ritrovate nel sistema finale Non ambiguità: il requisito deve soltanto avere una possibile interpretazione. L ambiguità può dipendere dallo stakeholder Completezza: tutti gli elementi importanti che sono rilevanti per soddisfare l utente devono essere considerati Consistenza: I requisiti devo essere consistenti verso loro stessi e verso i constraint importanti Valutati per importanza: ogni requisito deve essere valutato in termini di importanza, cioè di quanto esso è essenziale per il successo del progetto Stabilità: facilità che un requisito cambi Verificabilità: tutti i requisiti devono essere verificabili, cioè esiste un processo per controllare se il requisito è soddisfatto o no 14

15 Caratteristiche di qualità dei requisiti - Definizioni Modificabilità: tutti i requisiti devono essere modificabili. Fattibilità: tutti i requisiti devono essere implementati con le risorse, la tecnologia e budget. disponibili Giusto livello di dettaglio: l informazione contenuta nel requisito permette di ottenere la giusta comprensione e di iniziare l implementazione La testabilità del software IEEE Standard Glossary La testabilità del software è considerata sia dal punto di vista costruttivo che dei requisiti. (a) the degree to which the system or component facilitates the establishment of a test criteria and the performance of tests to determine whether those criteria have been met. (b) the degree to which a requirement is stated in terms that permit establishment of test design (and subsequently test cases) and execution of tests to determine whether the requirements have been met. 15

16 Requisito testabile Quando un requisito in linguaggio naturale può essere considerato testabile? Eseguire un test significa eseguire una funzione e osservare il verificarsi di un evento. Poiché i requisiti descrivono gli eventi accettabili che un sistema può generare, allora l evento specificato nel requisito deve essere eseguibile e osservabile Definizione di verifiability dello standards IEEE 830 IEEE Recommended Practice for Software Requirements Specifications : there exist some finite cost-effective process [executable] with which a person or machine can check that the software product meets the requirement [observable]. Origini dei problemi di testabilità Cause intra-requisito: dipende da come è scritto il requisito. Per esempio l uso di termini vaghi, imprecisi, frasi troppo complesse e mal strutturate. Cause inter-requisiti: inconsistenze semantiche (contraddizioni) Inconsistenze linguistiche (entità indicate con diverse terminologie, incompletezze, difetti nella struttura del documento dei requisiti requisiti mal posizionati) Cause extra-requisito Non implementabilità tecnica Barriere dovute ai formalismi usati 16

17 Migliorare la testabilità Tecniche Restrittive Tecniche restrittive: si limita il grado di libertà nello scrivere i requisiti per ridurne il grado di ambiguità. Requisiti più precisi ma meno comprensibili Classi di tecniche: Metodi basati su linguaggio naturale semplificato Metodi basati su linguaggio naturale strutturato Approcci basati sugli scenari Metodi basati sul Linguaggio semplificato 1986 Boeing ASD Simplified Technical English Standard di scrittura per documentazione tecnica di manutenzione aerospaziale Vocabolario, grammatica e stile di scrittura Iniziative per la scrittura dei requisiti: Attempt Controlled English (ACE), sottoinsieme dell inglese abbastanzasemplice da evitare ambiguità ma che permette di definre requisiti con lo stesso livello di rigore dei linguaggi di specifica formali Natural Language Processing (NLP) è una tecnica che controlla sui requisiti in linguaggio naturale il rispetto di regole definite come il vocabolario limitato, lo stile di costruzione delle frasi. Ogni frase è valutata con un ambiguity rate Linguaggio strutturato: basato sulla definizione l uso di regole o template per la strutturazione delle descrizioni dei requisiti 17

18 Metodi basati sugli Scenari Uno scenario corrisponde ad una sequenza temporale singola di interazioni fra componenti di un sistema Testing funzionale si può basare sulla riproduzione delle condizioni degli scenari per verificare la conformità del comportamento del sistema Migliorare la testabilità Tecniche Induttive Si parte dall identificazione di problemi diffusi e si definiscono raccomandazioni e linee guida per la stesura dei requisiti Ogni azienda ha le proprie regole per un buono stile di scrittura dei requisiti 18

19 Migliorare la testabilità Tecniche Analitiche Si basano sull analisi dei documenti di requisiti e sulla individuazione dei difetti Basate su tool automatici Tool: QuARS, ARM, LOLITA,TIGER PRO Manuali Formal Inspection Formal Inspection Conosciute dopo un articolo di Fagan (1976) che ha definito e strutturato l attività di revisione di documenti facendola diventare una metodologia Processo di Formal Inspection: Inizio dell ispezione: pianificazione delle risorse e dei tempi Ricerca dei difetti: analisi e report dei difetti trovati Raccolta dei difetti: i difetti vengono discussi e raccolti in una lista definitiva Correzione: viene richiesto agli autori dei documenti di correggere i difetti La fase più critica è la raccolta difetti che è sostenuta da tecniche di Reading 19

20 Reading Techniques L obiettivo è guidare l ispettore nell acquisizione di una comprensione più approfondita del prodotto ispezionato attraverso una serie di passi e procedure Alcune tecniche: Ad hoc: nessun supporto tecnico, solo l esperienza e le conoscenze dell ispettore Basate su check-list: le check-list servono per indicare all ispettore quali argomenti e aspetti specifici andare a considerare quanto legge il documento Basate su scenari: aiutano a concentrarsi su specifici tipi di difetti o proprietà del documento. Valutazione comparativa delle tecniche di miglioramento della testabilità dei requisiti Technique Cause of Poor Testability Intra-req. Inter-req. Extra-req. Analytic Tool based Manual A B C A C B Inductive A B C Simplified NL A C C Restrictive Structured NL B B B Behavioral B A B 20

21 Tecniche linguistiche per l analisi dei requisiti in linguaggio naturale Problemi affrontabili con l uso di tecniche di Natural Language Understanding : Espressiveness: the incorrect understanding of the meaning of the requirements, specifically ambiguities and poor readability. Consistency: the presence of semantic contradictions in the NL requirements documents. Completeness: the lack of necessary information QuARS sentences.txt Syntax Parser Parsed.txt Lexical Analysis Syntactic Analysis Views derivation metrics vague weak optional subjective multiple implicit underspec Logs Indicator-related dictionaries Domain dictionaries Graphics 21

22 Risultati di un rigoroso studio empirico Le performance dell utilizzo di QuARS sono state confrontate con quelle di un revisore esperto Medesimo insieme di documenti analizzati Registrazione dei tempi di review e dei difetti trovati dal tool e dal revisore Risultati: QuaRS ha una numero medio di difetti trovati all ora 32 volte maggiore del revisore Indipendentemente dal tempo QuaRS trova una numero di difetti triplo rispetto al revisore QuARS e il revisore sono complementari: 63% dei difetti trovati dal revisore non sono trovabili da QuARS I falsi positivi possono intaccare i risultati a sfavore di QuARS (se il rapporto fra FP e difetti reali > 6, QuARS è più costoso del revisore) QuARS si dovrebbe usare prima del revisore Requirements Quality Key Points La qualità dei requisiti in linguaggio naturale: definizione delle caratterisitiche Testabilità del software e requisiti testabili Cause di scarsa testabilità dei requisiti Tecniche per il miglioramento della testabilità Un tool per la valutazione della qualità dei requisiti 22

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

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

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

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

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

Dettagli

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

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

Dettagli

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

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

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

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

Tecniche e Strumenti per l Ingegneria dei Requisiti

Tecniche e Strumenti per l Ingegneria dei Requisiti Tecniche e Strumenti per l Ingegneria dei Requisiti Giuseppe Lami I.S.T.I. C.N.R. System & Software Evaluation Centre - Pisa Giuseppe.lami@isti.cnr.it - www.isti.cnr.it Argomenti Come si scrivono i requisiti

Dettagli

Collaudo e qualità del software Quali test eseguire

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

Dettagli

Lista delle descrizioni dei Profili

Lista delle descrizioni dei Profili Lista delle descrizioni dei Profili La seguente lista dei Profili Professionali ICT è stata definita dal CEN Workshop on ICT Skills nell'ambito del Comitato Europeo di Standardizzazione. I profili fanno

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

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

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

Dettagli

Classificazione Nuovo Esame PMP

Classificazione Nuovo Esame PMP Notizie sul nuovo esame PMP a partire dal Agosto 0 Classificazione Nuovo Esame PMP Questo è il link al documento del PMI: Crosswalk Between Current and New PMP Classifications del PMI Di seguito trovi

Dettagli

Ciclo di vita del progetto

Ciclo di vita del progetto IT Project Management Lezione 2 Ciclo di vita del progetto Federica Spiga A.A. 2009-2010 1 Ciclo di vita del progetto Il ciclo di vita del progetto definisce le fasi che collegano l inizio e la fine del

Dettagli

UniRoma2 - Ingegneria del Software 1 1

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

Dettagli

A3_1 V2.2 Analisi dei Requisiti e Specifica Significato, motivazioni e processi

A3_1 V2.2 Analisi dei Requisiti e Specifica Significato, motivazioni e processi Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A3_1 V2.2 Analisi dei Requisiti e Specifica Significato, motivazioni e processi Il contenuto del documento è liberamente

Dettagli

La Norma ISO 21500-1 Ed. 1-2012 Guidance on project management

La Norma ISO 21500-1 Ed. 1-2012 Guidance on project management 1 Per conto di AICQ CN 1 - Autore Giovanni Mattana - V. Presidente AICQ CN Presidente della Commissione UNI Gestione per la Qualità e Metodi Statistici INTERNATIONAL STANDARD ISO 21500 Peculiarità della

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

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

LINEA PROJECT MANAGEMENT

LINEA PROJECT MANAGEMENT LINEA PROJECT MANAGEMENT ITIL FOUNDATION V3 46.10.3 3 giorni Il corso, nell ambito della Gestione dei Servizi IT, mira a: 1. Comprendere Struttura e Processi di ITIL V3 - Information Technology Infrastructure

Dettagli

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

Sistemi elettronici per la sicurezza dei veicoli: presente e futuro. Il ruolo della norma ISO 26262 per la Sicurezza Funzionale 18 aprile 2012 Il punto di vista dell OEM sulla norma ISO 26262 per la Sicurezza Funzionale dei veicoli: la sfida dell integrazione nei processi aziendali Marco Bellotti Functional Safety Manager Contenuti

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

Verifica e Validazione del Simulatore

Verifica e Validazione del Simulatore Verifica e del Simulatore I 4 passi principali del processo simulativo Formulare ed analizzare il problema Sviluppare il Modello del Sistema Raccolta e/o Stima dati per caratterizzare l uso del Modello

Dettagli

Project Management e Business Analysis: the dynamic duo. Firenze, 25 Maggio 2011

Project Management e Business Analysis: the dynamic duo. Firenze, 25 Maggio 2011 Project Management e Business Analysis: the dynamic duo Firenze, 25 Maggio 2011 Grazie! Firenze, 25 Maggio 2011 Ing. Michele Maritato, MBA, PMP, CBAP 2 E un grazie particolare a www.sanmarcoinformatica.it

Dettagli

CONCETTI DI BASE PER LA QUALITA

CONCETTI DI BASE PER LA QUALITA CONCETTI DI BASE PER LA QUALITA Misura: è una funzione m: A -> B che associa ad ogni attributo A di un osservabile nel mondo reale o empirico (dominio) un oggetto formale B nel mondo matematico (range);

Dettagli

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

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti Sviluppo Agile [Cockburn 2002] Extreme Programming (XP) [Beck 2000] Sono più importanti auto-organizzazione, collaborazione, comunicazione tra membri del team e adattabilità del prodotto rispetto ad ordine

Dettagli

Gestione dello sviluppo software Modelli Agili

Gestione dello sviluppo software Modelli Agili Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi A4_3 V1.1 Gestione dello sviluppo software Modelli Agili Il contenuto del documento è liberamente utilizzabile dagli

Dettagli

Ingegneria del Software

Ingegneria del Software Ingegneria del Software Processi di Sviluppo Agile Origini dello Sviluppo Agile Proposta di un gruppo di sviluppatori che rilevava una serie di criticità degli approcci convenzionali: Troppa rigidità dei

Dettagli

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

REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA

REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA SETTORE ECONOMICO PROFESSIONALE 1 SETTORE MECCANICA;PRODUZIONE E MANUTENZIONE DI MACCHINE;IMPIANTISTICA Processo Lavorazioni aeronautiche

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

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

Dettagli

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

Giuseppe Santucci. Qualità nella Produzione del Software

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

Dettagli

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

PROGETTO SOCIALE D INIZIATIVA WIN (WELLFARE DI INIZIATIVA).

PROGETTO SOCIALE D INIZIATIVA WIN (WELLFARE DI INIZIATIVA). PROGETTO SOCIALE D INIZIATIVA WIN (WELLFARE DI INIZIATIVA). Ing Paolo Neri 4 Settembre 2014 Associazione Vecchie e Nuove Povertà Empoli IL «PROGETTO SOCIALE D INIZIATIVA» Missione: favorire l uscita dal

Dettagli

IS Governance. Francesco Clabot Consulenza di processo. francesco.clabot@netcom-srl.it

IS Governance. Francesco Clabot Consulenza di processo. francesco.clabot@netcom-srl.it IS Governance Francesco Clabot Consulenza di processo francesco.clabot@netcom-srl.it 1 Fondamenti di ISO 20000 per la Gestione dei Servizi Informatici - La Norma - 2 Introduzione Che cosa è una norma?

Dettagli

02: Project Management

02: Project Management 02: Project Management Le tre P del project management Persone motivate / esperte SEI PM-CMM (People Management Capability Maturity Model) assunzione / selezione addestramento / cultura di gruppo stipendio

Dettagli

Gestione di progetto: pianificazione. Introduzione: dove siamo? Introduzione: pianificazione. Simona Bernardi

Gestione di progetto: pianificazione. Introduzione: dove siamo? Introduzione: pianificazione. Simona Bernardi Gestione di progetto: pianificazione Simona Bernardi Corso di Ingegneria del Software 04/ 05 Prof.Susanna Donatelli Introduzione: dove siamo? Gestione di progetto: Pianificazione Monitoraggio e controllo

Dettagli

Scrivere (e leggere) i requisiti di un prodotto software

Scrivere (e leggere) i requisiti di un prodotto software Scrivere (e leggere) i requisiti di un prodotto software Prof. Paolo Ciancarini Corso di Ingegneria del Software CdL Informatica Università di Bologna Obiettivi Cosa sono i requisiti di un software? Analisi

Dettagli

ISO Revisions Whitepaper

ISO Revisions Whitepaper ISO Revisions ISO Revisions ISO Revisions Whitepaper Processi e procedure Verso il cambiamento Processo vs procedura Cosa vuol dire? Il concetto di gestione per processi è stato introdotto nella versione

Dettagli

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

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

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

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

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

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

Principi dell ingegneria del software Relazioni fra

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

Dettagli

DDL, VINCOLI D INTEGRITÁ, AGGIORNAMENTI E VISTE. SQL è più di un semplice linguaggio di interrogazione

DDL, VINCOLI D INTEGRITÁ, AGGIORNAMENTI E VISTE. SQL è più di un semplice linguaggio di interrogazione SQL DDL, VINCOLI D INTEGRITÁ, AGGIORNAMENTI E VISTE SQL è più di un semplice linguaggio di interrogazione! Linguaggio di definizione dati (Data-definition language, DDL):! Crea/distrugge/modifica relazioni

Dettagli

Ingegneria del Software. Processi di Sviluppo

Ingegneria del Software. Processi di Sviluppo Ingegneria del Software Processi di Sviluppo Ingegneria del Software: Tecnologia Stratificata tools metodi processi Focus sulla qualità Ingegneria del Software: Tecnologia Stratificata (2) Qualità Elemento

Dettagli

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

figure professionali software

figure professionali software Responsabilità del Program Manager Valuta la fattibilità tecnica delle opportunità di mercato connesse al programma; organizza la realizzazione del software in forma di progetti ed accorpa più progetti

Dettagli

4.1 Che cos è l ideazione

4.1 Che cos è l ideazione Luca Cabibbo Analisi e Progettazione del Software Ideazione (non è la fase dei requisiti) Capitolo 4 marzo 2013 Il meglio è nemico del bene. Voltaire 1 *** AVVERTENZA *** I lucidi messi a disposizione

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

La portata del software

La portata del software La portata del software Portata Contesto. In che modo il software in costruzione si inserirà nel sistema, prodotto o contesto aziendale esistente e quali vincoli impone il contesto? Obiettivi relativi

Dettagli

Sistemi di Gestione: cosa ci riserva il futuro? Novità Normative e Prospettive

Sistemi di Gestione: cosa ci riserva il futuro? Novità Normative e Prospettive Comitato SGQ Comitato Ambiente Sistemi di Gestione: cosa ci riserva il futuro? Novità Normative e Prospettive Mercoledì, 23 febbraio 2005 - Palazzo FAST (Aula Morandi) Piazzale Morandi, 2 - Milano E' una

Dettagli

Gestione dei Progetti (2005-2006)

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

Dettagli

Project Management & Innovazione

Project Management & Innovazione Project Management & Innovazione Milano, 24 ottobre 2006 Antonio Bassi, PMP antonio.bassi@pmi-nic.org www.pmi-nic.org Agenda Il progetto La ricerca L evoluzione Il libro e poi Ambito e missione del progetto

Dettagli

Qualità del Software - una panoramica -

Qualità del Software - una panoramica - Qualità del Software - una panoramica - More Quality, More World, More Future [Finmeccanica 2007] Dott. Alan Franzi Ing. Francesca Malcotti - Politecnico di Milano Indice della presentazione Panoramica

Dettagli

Software. Engineering

Software. Engineering Software Engineering Agenda Scenario nel quale matura la necessità di esternalizzare Modalità conrattuali, ambito, livelli di servizio Modalità di governo del contratto e di erogazione dei servizi Metodologia

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

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

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

Dettagli

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

Domenico Ercolani Come gestire la sicurezza delle applicazioni web

Domenico Ercolani Come gestire la sicurezza delle applicazioni web Domenico Ercolani Come gestire la sicurezza delle applicazioni web Agenda Concetti generali di sicurezza applicativa La soluzione IBM La spesa per la sicurezza non è bilanciata Sicurezza Spesa Buffer Overflow

Dettagli

I MODELLI STATISTICO-MATEMATICI PER I MERCATI DELL ENERGIA DAL MONDO ACCADEMICO ALL'INDUSTRIA

I MODELLI STATISTICO-MATEMATICI PER I MERCATI DELL ENERGIA DAL MONDO ACCADEMICO ALL'INDUSTRIA I MODELLI STATISTICO-MATEMATICI PER I MERCATI DELL ENERGIA DAL MONDO ACCADEMICO ALL'INDUSTRIA PADOVA, 10 MAGGIO 2013 DIPARTIMENTO DI SCIENZE STATISTICHE Cosa fornisce il mondo Accademico DAL PROGETTO ALL

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

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

Processi di Gestione dei Sistemi ICT

Processi di Gestione dei Sistemi ICT Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi A3_1 V1.1 Processi di Gestione dei Sistemi ICT Il contenuto del documento è liberamente utilizzabile dagli studenti,

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 1

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

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

Introduzione al Project Management

Introduzione al Project Management IT Project Management Lezione 1 Introduzione al Project Management Federica Spiga A.A. 2009-2010 1 Rapporto CHAOS 2009 Progetti completati in tempo, all interno del budget, rispettando i requisiti RAPPORTO

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

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13 Raccolta dei Requisiti con i Casi D'uso Corso di Ingegneria del Software Anno Accademico 2012/13 I casi d uso I casi d'uso (use case) sono una tecnica utilizzata per identificare i requisiti funzionali

Dettagli

Modello OAIS. Modello di riferimento. Il Modello. Prof.ssa E. Gentile a.a. 2011-2012. Un modello di riferimento dovrebbe descrivere:

Modello OAIS. Modello di riferimento. Il Modello. Prof.ssa E. Gentile a.a. 2011-2012. Un modello di riferimento dovrebbe descrivere: Modello OAIS Prof.ssa E. Gentile a.a. 2011-2012 Prof.ssa E. Gentile Progettazione e Produzione di Contenuti Digitali 1 Modello di riferimento Un modello di riferimento dovrebbe descrivere: le componenti

Dettagli

Qualità del software. Tecniche di Programmazione 2009/10. Giovanni A. Cignoni - http://www.di.unipi.it/~giovanni/ 1. contenuti. definizione di qualità

Qualità del software. Tecniche di Programmazione 2009/10. Giovanni A. Cignoni - http://www.di.unipi.it/~giovanni/ 1. contenuti. definizione di qualità Qualità del software Tecniche di Programmazione Lez. 05 Università di Firenze a.a. 2009/10, I semestre 1/33 contenuti Qualità? Definizioni Il prodotto software Modelli della qualità per il sw: ISO/IEC

Dettagli

TED LEWIS ROMA 16-17 APRILE 2007 ROMA 18-19 APRILE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

TED LEWIS ROMA 16-17 APRILE 2007 ROMA 18-19 APRILE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA TED LEWIS MANAGEMENT MODELING AND ANALYSIS ROMA 16-17 APRILE 2007 ROMA 18-19 APRILE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli

IL PERFORMANCE MANAGEMENT

IL PERFORMANCE MANAGEMENT IT PROFESSIONAL SERVICES UNA SOLUZIONE PER IL PERFORMANCE MANAGEMENT for Enterprise Gestire il portfolio applicativo monitorando qualità, produttività e costi dello sviluppo applicativo Overview ARGOMENTI:

Dettagli

La qualità delle informazioni:

La qualità delle informazioni: misurazione e controllo in Enterprise Data Warehouse FABIO BALDUZZI ICTEAM Torino / Direttore Tecnico 0 Dati strutturati INFORMAZIONI DMS Dati non strutturati DATI Contesto Esperienza Enterprise Knowledge

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Requisiti sulla qualità del software secondo lo standard ISO/IEC 25010

Requisiti sulla qualità del software secondo lo standard ISO/IEC 25010 1. Premessa. Requisiti sulla qualità del software secondo lo standard ISO/IEC 25010 Domenico Natale AB Medica Versione 1 Riunione delle Commissione UNINFO Informatica Medica Milano, 30 settembre 2013 La

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

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

Sillabo. REQB Certified Professional for Requirements Engineering. Livello Foundation

Sillabo. REQB Certified Professional for Requirements Engineering. Livello Foundation Sillabo REQB Certified Professional for Livello Foundation Version 2.1 2014 I diritti di autore (copyright) di questa edizione del Sillabo, sono di REQB e ITA-STQB Storia delle modifiche Versione Data

Dettagli

Gruppo Boehringer Ingelheim Italia ITIL: la consapevolezza del servizio che completa il manager

Gruppo Boehringer Ingelheim Italia ITIL: la consapevolezza del servizio che completa il manager Gruppo Boehringer Ingelheim Italia ITIL: la consapevolezza del servizio che completa il manager Ing. Filippo Ermini Ing. Andrea Pini Chi è Boehringer Ingelheim MONDO: Medicina umana e veterinaria Ingelheim

Dettagli

Il data quality nei progetti IRB e nel processo creditizio. Vincenzo M. Re

Il data quality nei progetti IRB e nel processo creditizio. Vincenzo M. Re Il data quality nei progetti IRB e nel processo creditizio Vincenzo M. Re Il documento riflette le opinioni personali del relatore che non possono in alcun modo essere ritenute espressione della posizione

Dettagli

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

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

Dettagli

Ingegneria dei sistemi (System Engineering ESA, Systems Engineering - NASA) Appunti schematici

Ingegneria dei sistemi (System Engineering ESA, Systems Engineering - NASA) Appunti schematici Ingegneria dei sistemi (System Engineering ESA, Systems Engineering - NASA) Appunti schematici Riferimenti Testo di riferimento: NASA Systems Engineering Handbook (NASA-SEH) Utili anche i documenti di

Dettagli

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Business white paper Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Indice 3 Sommario esecutivo 3 Introduzione 3 Best practice a livello aziendale 5 Best practice a

Dettagli

Francesco Scribano GTS Business Continuity and Resiliency services Leader

Francesco Scribano GTS Business Continuity and Resiliency services Leader Francesco Scribano GTS Business Continuity and Resiliency services Leader Certificazione ISO 27001: l'esperienza IBM Certificazione ISO 27001: l'esperienza IBM Il caso di IBM BCRS Perchè certificarsi Il

Dettagli

Vincoli di Integrità Approccio dichiarativo alla loro implementazione

Vincoli di Integrità Approccio dichiarativo alla loro implementazione Vincoli di Integrità Approccio dichiarativo alla loro implementazione Antonella Poggi Dipartimento di informatica e Sistemistica SAPIENZA Università di Roma Progetto di Applicazioni Software Anno accademico

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

11. Evoluzione del Software

11. Evoluzione del Software 11. Evoluzione del Software Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 11. Evoluzione del Software 1 / 21 Evoluzione del Software - generalità Cosa,

Dettagli

Lezione 10 Business Process Modeling

Lezione 10 Business Process Modeling Lezione 10 Business Process Modeling Ingegneria dei Processi Aziendali Modulo 1 - Servizi Web Unità didattica 1 Protocolli Web Ernesto Damiani Università di Milano Step dell evoluzione del business process

Dettagli

Metodologia TenStep. Maggio 2014 Vito Madaio - TenStep Italia

Metodologia TenStep. Maggio 2014 Vito Madaio - TenStep Italia Metodologia TenStep Maggio 2014 Vito Madaio - TenStep Italia Livello di Complessità Processo di Project Management TenStep Pianificare il Lavoro Definire il Lavoro Sviluppare Schedulazione e Budget Gestire

Dettagli

Il processo di sviluppo sicuro. Kimera Via Bistolfi, 49 20134 Milano www.kimera.it info@kimera.it

Il processo di sviluppo sicuro. Kimera Via Bistolfi, 49 20134 Milano www.kimera.it info@kimera.it Il processo di sviluppo sicuro Kimera Via Bistolfi, 49 20134 Milano www.kimera.it info@kimera.it Kimera Via Bistolfi, 49 20134 Milano www.kimera.it info@kimera.it Argomenti: Perchè farlo Il processo di

Dettagli

Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza. Roberto Ugolini roberto.ugolini@postecom.it

Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza. Roberto Ugolini roberto.ugolini@postecom.it Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza Roberto Ugolini 1 Il processo di sviluppo sicuro del codice (1/2) Il processo di sviluppo sicuro del codice () è composto

Dettagli

NetQues Project Report Speech and Language Therapy Education in Europe United in Diversity

NetQues Project Report Speech and Language Therapy Education in Europe United in Diversity NetQues Project Report Speech and Language Therapy Education in Europe United in Diversity Network for Tuning Standards and Quality of Education Programmes in Speech and Language Therapy/Logopaedics across

Dettagli