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

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

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

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

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

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

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

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

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

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

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Come favorire la competitività e la sostenibilità con la nuova ISO 9001:2015

Come favorire la competitività e la sostenibilità con la nuova ISO 9001:2015 Come favorire la competitività e la sostenibilità con la nuova ISO 9001:2015 Lucio Galdangelo - Fieramilano 02/10/2014 Come cambierà la norma ISO 9001 2015 ISO 9001:2015 2012 New Work Item Proposal per

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

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al.

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al. Modello Code and fix Processo parte III Leggere Sez. 7.4 Ghezzi et al. Modello iniziale Iterazione di due passi scrittura del codice correzione degli errori Problemi: dopo una serie di cambiamenti, la

Dettagli

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

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

Il software nel settore aerospaziale: indicazioni per la certificazione

Il software nel settore aerospaziale: indicazioni per la certificazione Il software nel settore aerospaziale: indicazioni per la certificazione 1 AGENDA Criticità del software nel settore aerospaziale Standard di riferimento esistenti e loro similitudini/differenze (panoramica

Dettagli

SCD IS. Processi software. Processi Software. UniPD - 2009 - Ingegneria del Software mod. A 1. Definizioni. Modelli di ciclo di vita

SCD IS. Processi software. Processi Software. UniPD - 2009 - Ingegneria del Software mod. A 1. Definizioni. Modelli di ciclo di vita Processi software Anno accademico 2009/10 Ingegneria del mod. A Tullio Vardanega, tullio.vardanega@math.unipd.it SCD IS Definizioni Ciclo di vita Copre l evoluzione di un prodotto dal concepimento al ritiro

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

Giuseppe Santucci. Qualità nella Produzione del Software. 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System)

Giuseppe Santucci. Qualità nella Produzione del Software. 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System) Giuseppe Santucci Qualità nella Produzione del Software 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System) 02SQAS.1 Peculiarità del SW XXX warrants that the media (!) on which

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

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

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

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

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

Metodi Formali nell Ingegneria del Software (Laurea Specialistica Ing.Informatica) A.A. 2005-06 Marco Cadoli

Metodi Formali nell Ingegneria del Software (Laurea Specialistica Ing.Informatica) A.A. 2005-06 Marco Cadoli Metodi Formali nell Ingegneria del Software (Laurea Specialistica Ing.Informatica) A.A. 2005-06 Marco Cadoli Università di Roma La Sapienza Dipartimento di Informatica e Sistemistica PRIMA PARTE Il ruolo

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

ACRL Association of College and Research Libraries

ACRL Association of College and Research Libraries ACRL Association of College and Research Libraries Standard delle competenze per il possesso dell informazione (information literacy) nell educazione superiore Standard, indicatori di performance, obiettivi

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

Studio di fattibilità (2) Identificazione ed analisi dei requisiti

Studio di fattibilità (2) Identificazione ed analisi dei requisiti Prime fasi nella produzione del software &RUVR GL,QJHJQHULD GHO 6RIWZDUH Capitolato d appalto o doc. formale di richiesta prodotto Incontri con il committente e/o interviste Esercitazione Studio del dominio

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

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

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

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

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

5. Requisiti del Software II

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

Dettagli

Software project management. www.vincenzocalabro.it

Software project management. www.vincenzocalabro.it Software project management Software project management Sono le attività necessarie per assicurare che un prodotto software sia sviluppato rispettando le scadenze fissate rispondendo a determinati standard

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

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

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi metodologie a.a. 2003-2004 1 metodologia una serie di linee guida per raggiungere certi obiettivi più formalmente: un processo da seguire documenti o altri elaborati da produrre usando linguaggi più o

Dettagli

Obiettivo della lezione. Casi d uso. Casi d uso (use cases) Scenari d interazione

Obiettivo della lezione. Casi d uso. Casi d uso (use cases) Scenari d interazione Obiettivo della lezione Casi d uso La modellazione dei requisiti funzionali I casi d uso Gli attori Gli scenari Come scrivere casi d uso Casi d uso (use cases) Scenari d interazione Proposti da Ivar Jacobson

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

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

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

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

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

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

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

GUFPI-ISMA. Evoluzione delle Linee Guida: l utilizzo contrattuale dei Function Points. Roberto Meli

GUFPI-ISMA. Evoluzione delle Linee Guida: l utilizzo contrattuale dei Function Points. Roberto Meli GUFPI-ISMA Evoluzione delle Linee Guida: l utilizzo contrattuale dei Function Points Roberto Meli Coordinatore Consiglio Direttivo GUFPI-ISMA 2 Perché era necessario intervenire? I contratti per il software

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

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

Architettura del software: dai requisiti ai casi d'uso

Architettura del software: dai requisiti ai casi d'uso Architettura del software: dai requisiti ai casi d'uso Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL

Dettagli

LEZIONE 11 - Design Antipatterns

LEZIONE 11 - Design Antipatterns Laboratorio di Ingegneria del Software a.a. 2013-2014 LEZIONE 11 - Design Antipatterns Catia Trubiani Gran Sasso Science Institute(GSSI), L Aquila catia.trubiani@gssi.infn.it Indice - Contesto: cos è un

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

Echi da Amsterdam. Titolo: Sintesi presentazioni Metodologia Agile. Sintesi del Leadership Meeting e dell EMEA Congress 2009. Relatore: Bruna Bergami

Echi da Amsterdam. Titolo: Sintesi presentazioni Metodologia Agile. Sintesi del Leadership Meeting e dell EMEA Congress 2009. Relatore: Bruna Bergami Echi da Amsterdam Sintesi del Leadership Meeting e dell EMEA Congress 2009 Titolo: Sintesi presentazioni Metodologia Agile Relatore: Bruna Bergami PMI NIC - Tutti i diritti riservati Milano, 19 Giugno

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

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

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

Le norme della Qualità

Le norme della Qualità Le norme ISO9000 e la loro evoluzione L evoluzione delle ISO 9000 in relazione alla evoluzione delle prassi aziendali per la Qualita 3 Evoluzione della serie ISO 9000 2 1 Rev. 1 ISO 9000 Rev. 2 ISO 9000

Dettagli

Glossario Standard dei termini usati nell Ingegneria dei Requisiti

Glossario Standard dei termini usati nell Ingegneria dei Requisiti Glossario Standard dei termini usati nell Ingegneria dei Requisiti Versione 1 (15 aprile 2013) Prodotto dal Board DOCUMENTO DI TRACCIABILITÁ DEI TERMINI tra GLOSSARIO REQB in LINGUA e GLOSSARIO ITA-REQB

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

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

Laboratorio di Progettazione di Sistemi Software Introduzione

Laboratorio di Progettazione di Sistemi Software Introduzione Laboratorio di Progettazione di Sistemi Software Introduzione Valentina Presutti (A-L) Riccardo Solmi (M-Z) Indice degli argomenti Introduzione all Ingegneria del Software UML Design Patterns Refactoring

Dettagli

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

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 12: Metodologie: controllo qualità P.M. Fase 3-4: tracking di progetto, introduzione Prof.ssa R. Folgieri email: folgieri@dico.unimi.it

Dettagli

Dalla motivazione del personale al miglioramento della qualità dei Servizi Sanitari

Dalla motivazione del personale al miglioramento della qualità dei Servizi Sanitari Dalla motivazione del personale al miglioramento della qualità dei Servizi Sanitari Definizione di progetto Cos è un progetto Progetto si definisce, di regola, uno sforzo complesso di durata solitamente

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

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

Marco Lazzari - Appunti sulla qualità dei siti web

Marco Lazzari - Appunti sulla qualità dei siti web Marco Lazzari - Appunti sulla qualità dei siti web Università di Bergamo, 2004 Una classificazione dei siti web intranet: reti aziendali enterprise information portals: accesso a informazioni e servizi

Dettagli

Pattern Architetturali e Analisi Architetturale

Pattern Architetturali e Analisi Architetturale Pattern Architetturali e Analisi Architetturale Ingegneria del Software parte II Andrea Bei Pattern Architetturali Pattern Architetturale Descrive il modello organizzativo strutturale di un sistema software

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

Processi per lo sviluppo rapido del software

Processi per lo sviluppo rapido del software Lezione 3 Processi per lo sviluppo rapido del software Sviluppo Rapido del Software Slide 1 Riferimenti bibliografici I. Sommerville Ingegneria del Software 8a edizione Cap.17 R. Pressman- Principi di

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

Il Progetto ECCE Un esperienza locale ed europea tra Università e Impresa

Il Progetto ECCE Un esperienza locale ed europea tra Università e Impresa Il Progetto ECCE Un esperienza locale ed europea tra Università e Impresa Giornata Erasmus 2011 Monitoraggio del rapporto Università e Impresa Roma, 17 febbraio 2011 This project has been funded with support

Dettagli