”OSSERVAZIONE”: l’esplorazione del processo. ELENCO DELLE PERSONE CHE HANNO COLLABORATO ALLA RICOSTRUZIONE DEL PROCESSO REALE CSCCACCCDCAV&VPE LEADER.

Slides:



Advertisements
Presentazioni simili
Linguaggio C e C++.
Advertisements

Renzo Marin – CRC Veneto Progetto CRC-CNIPA
Il laboratorio (spazio web)
20/04/2006 COO-RU- Organizzazione Operativa 1 STRUTTURE SIN/ELI Struttura organizzativa COO/RU – Organizzazione Operativa 12 settembre 2007.
La progettazione secondo la norma internazionale ISO 9001
Informatica e Telecomunicazioni
PORTFOLIO Grumo Nevano C.D. "Pascoli" Profilo
Gestione dei laboratori Come rendere sicura la navigazione internet e l'uso della rete Lorenzo Nazario.
L’Informatica dal Problema alla Soluzione
1 14. Verifica e Validazione Come assicurarsi che il software corrisponda alle necessità dellutente? Introdurremo i concetti di verifica e validazione.
DIFFICOLTA’ DEL LINGUAGGIO
Introduzione allinformatica. Cosè linformatica ? Scienza della rappresentazione e dellelaborazione dellinformazione ovvero Studio degli algoritmi che.
Corso di Informatica per Giurisprudenza Lezione 5
1Milano, 3 Novembre 2004Assemblea Nazionale FISM WORKSHOP La certificazione dei requisiti di qualità per le Società Medico-Scientifiche Presentazione del.
Progettazione di una base di dati
Gaetano Santucci Centro Nazionale per l’Informatica
BRIDGE-3K Verso il futuro La migrazione dai sistemi HP3000. Un ponte verso il futuro conservando la cultura e le risorse aziendali. NOVITA 2007.
La progettazione di un sistema informatico
INTEGRAZIONE, RILASCIO
03 - IL “CICLO DI VENDITA” DELLA DOMOTICA
LA QUALITA’ NELLA PROGRAMMAZIONE DELL’ESERCIZIO
PROBLEMI E “PAROLACCE” Nucleo: Relazioni e Funzioni
Lo sviluppo del progetto informatico
VIRTUALIZZAZIONE Docente: Marco Sechi Modulo 1.
Servizi Grid ed agenti mobili : un ambiente di sviluppo e delivering
Programma di Informatica Classi Prime
(Una) Definizione di Ingegneria del Software (IEEE) Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio.
COME FORMARE LE STRUTTURE OPERATIVE DELLA COMMITTENZA Per assumere scelte decisionali con piena consapevolezza delle loro implicazioni Per elaborare e.
Universita’ degli Studi Roma Tre
LABVIEW Sommario Che cosa è uno strumento virtuale (VI) creato con LABVIEW Parti di un VI: pannello frontale diagramma a blocchi Confronto tra il principio.
Definizione(i) di Ingegneria del Software (IEEE) Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio e.
Controllo di gestione, strumenti di pianificazione
LE PROCEDURE OPERATIVE NEL MANUALE DELLA QUALITA’ UNI EN ISO 9004:2009
Università di Macerata - P. Cioni1 Economia delle aziende di assicurazione La Circolare Isvap n. 577/D: “Disposizioni in materia di sistema dei controlli.
Tecnologie Informatiche ed Elettroniche per le Produzioni Animali (corso TIE) CORSO LAUREA MAGISTRALE IN SCIENZE E TECNOLOGIE DELLE PRODUZIONI ANIMALI.
Sistema pubblico di connettività Cooperazione Applicativa Cooperazione Applicativa Roberto Benzi 30 giugno 2005.
Qualità nei laboratori di ricerca e albo laboratori altamente specializzati Workshop, Genova 08 novembre 2002 G.B. Rossi: Qualità e miglioramento nei laboratori.
II - Approccio progettuale
“INCONSAPEVOLI” ESPERIENZE DI Extreme Programming Genova, 29 Ottobre 2002.
Master MATITCiclo di vita del Sistema Informativo1 CICLO DI VITA DEL SISTEMA INFORMATIVO.
Le norme ISO 9000 ed il Manuale della Qualità
Progettazione di basi di dati: metodologie e modelli
SnippetSearch Database di snippet bilanciato e replicato di Gianluigi Salvi Reti di calcolatori LS – Prof. A.Corradi.
IL PROCESSO DI GESTIONE DELLA PRESTAZIONE La gestione della prestazione è innanzi tutto un approccio finalizzato al miglioramento ed allo sviluppo della.
IPSIA A. Ferrari - Maranello
Un nuovo modello di governo della formazione territoriale Sviluppo di un servizio di formazione continua sul territorio Ufficio Formazione.
12 dicembre Analisi di sicurezza dell’applicazione SISS Security Assessment dell’applicativo e Reversing del client.
Le basi di dati.
II FASE - Linea d’azione 2 “Il riuso delle soluzioni di eGovernment” 10 maggio 2004 Roberto Pizzicannella CNIPA – Area Innovazione Regioni ed Enti Locali.
Metropolitana di Genova – Porte di salita passeggeri
Catania, 13 Novembre 2015Workshop Finale del Progetto VESPA1 Virtual Environment for a Superior Neuro-PsichiAtry PO FESR Line Project.
Applicazione Presentazione Sessione Trasporto Rete Data link Fisico OSI Processo / Applicazione Trasporto Rete- Internet Interfaccia di.
Stage di LODETTI ELENA – CLASSE III LICEO LINGUISTICO GIURIDICO- ECONOMICO C/o GCA SRL DI COMUN NUOVO.
Tipi di Computer MainframeSupercomputerMinicomputerMicrocomputerHome Computer Personal Computer WorkstationMicrocontrollori Sistemi Barebone.
Procedura Acquisti. Norme Generali All’inizio di ogni anno fino il Direttore provvede alla nomina annuale dei RUP (Responsabile Unico del Procedimento)
Implementazioni di un analizzatore di protocollo Esistono quattro fondamentali tradeoff per la realizzazione di un analizzatore di protocollo:  Analisi.
IL PROCESSO SOFTWARE EMERSO DALLA DOCUMENTAZIONE.
Dispositivi di comando e controllo Dispositivi a logica programmabile.
Dal problema al programma – ciclo di sviluppo del software La scrittura del programma è solo una delle fasi del processo di sviluppo di un'applicazione.
IL PROGETTO INFORMATICO
Management e Certificazione della Qualità Prof. Alessandro Ruggieri.
Prof.ssa Cecilia Silvestri - A.A. 2014/2015. Punti Norma ISO 9001 Prof.ssa Cecilia Silvestri - A.A. 2014/2015.
ALGORITMI, LINGUAGGI E PROGRAMMI Facoltà di Lingue e Letterature Straniere Corso di laurea in Relazioni Pubbliche.
Baggiovara,9-23 Ottobre ° giornata Corso formazione CCM Il modello di Accreditamento istituzionale della Regione Emilia-Romagna Baggiovara,9-23 Ottobre.
I PROSSIMI STEP. SEDUTE DI BRAINSTORMING PER PROPORRE SOLUZIONI ALLE CRITICITA’ DEL PROCESSO. DEFINIZIONE DI METRICHE PER VALUTARE LE PRESTAZIONI DEL.
Triggers and actions L’inizializzazione di un trigger permette di avviare delle azioni automatiche a partire da eventi significativi. Possibili azioni.
La valutazione del SW contabile Manuela Bertei
1 6 APRILE 2016 Corso Bilanci XBRL novità tassonomia 2015.
Alessandro Tirel - Sezione di Trieste Storage servers & TCP Tuning Proposta di studio delle problematiche connesse alla fornitura di servizi di storage.
TQM Consult SpA XXXIX Congresso Nazionale U.G.D.C.TREVISO, marzo 2001 LA CERTIFICAZIONE DI QUALITA’ DELLE PROFESSIONI INTELLETTUALI LA QUALITA’ DEI.
Transcript della presentazione:

”OSSERVAZIONE”: l’esplorazione del processo

ELENCO DELLE PERSONE CHE HANNO COLLABORATO ALLA RICOSTRUZIONE DEL PROCESSO REALE CSCCACCCDCAV&VPE LEADER PE1 UNITA’LEADER UNITA’LEADERUNITA’PE2 LEADER UNITA’PE3 LEADER PE4 LEADER UNITA’PE5 LEADERUNITA’ LEADERUNITA’ LEADER

INTERVENTO DELLA V&V Nel 2007 si forma il nuovo team di lavoro V&V che si propone di attuare ciò che finora era stato previsto dalla normativa CEI EN 50128, ma che non era mai stato messo in pratica, programmando attività di verifica e nuove procedure di validazione.

NUOVI TOOL SW

Il lavoro dei SISTEMISTI Il sistemista è colui che si occupa di definire l’architettura di sistema, analizzando e interpretando i capitolati forniti dal cliente, per poi redigere un documento SFD di Specifica dei Requisiti funzionali di veicolo, che dovrà costituire un punto di partenza per il lavoro dei progettisti.

Il lavoro dei SISTEMISTI Nella sede di Napoli lavora un solo sistemista. Gli altri sistemisti del processo lavorano presso un’altra sede dell’azienda. Per alcune commesse il sistemista può essere una società esterna. Per molte commesse i progettisti possono essere anche sistemisti.

DOCUMENTAZIONE IN INGRESSOIN USCITA CAPITOLATISCHEMI DI PRINCIPIO DOCUMENTAZIONE DI OFFERTA DELL’AZIENDA DOCUMENTI PRESTAZIONALI NORMATIVE DI RIFERIMENTOSPECIFICHE DEI REQUISITI DEGLI IMPIANTI: architettura impianto, requisiti funzionali, interfacce col sistema di controllo, requisiti di diagnostica. REQUISITI DI SICUREZZADOCUMENTO DI TRAFFICO DATI

Programma di simulazione: MATLAB Linguaggio di programmazione: C Ambiente di sviluppo: MICROVISION Ambiente di simulazione: BORLAND C e QUICK BASIC Strumenti software adottati

Il CAPITOLATO TECNICO o SPECIFICA DI FORNITURA contiene le richieste del cliente. Nella maggioranza dei casi questa documentazione risulta sommaria e non esaustiva. Difficoltà per progettisti e sistemisti nel definire le Specifiche dei Requisiti di Sistema e del SW. Problemi col cliente e demotivazione degli attori del processo.

Il fatto che i requisiti di partenza siano poco chiari e incompleti causa l’esigenza di continue azioni correttive e retroazioni durante il processo. In genere le retroazioni sono dovute a: 1.Mancanza di rispondenza dei risultati ai requisiti richiesti 2.Nuove richieste del cliente 3.Aggiornamenti voluti dai progettisti

PROCESSO PROGETTAZIONE CS le fasi

PRESENZA DI CICLI ANALISI DEI REQUISITI FUNZIONALI E VERIFICA DI FATTIBILITA’ DEFINIZIONE REQUISITI FUNZIONALI DI VEICOLO TEST DI INTEGRAZIONE IN LABORATORIO IMPLEMENTAZIONE O PROGETTAZIONE PROGETTAZIONE O ARCHITETTURA DI SISTEMA TEST DI INTEGRAZIONE DEL SW SULLA MACCHINA

DOCUMENTAZIONE PROCESSO IN INGRESSOIN USCITAFASE CORRISPONDENTE CAPITOLATISpecifica dei Requisiti del sw SRS (253) Progettazione di Massima Specifica dei requisiti funzionali di veicolo SFD Specifica di Prova dei requisiti del sw o Specifica di test del sw STS (258) Progettazione di Massima Requisiti RAMSDescrizione del sw SDD (252)Progettazione di Massima Piano di Assicurazione della Qualità del sw Descrizione di dettaglio del sw DSDD Progettazione di Dettaglio Manuale di CodificaSpecifica di Prova del Modulo sw o Specifica di Test del modulo sw SMTS Progettazione di Dettaglio CODICE SORGENTECODIFICA Rapporto di prova del sw o SW Test Report STR (257) Validazione (Testing di Sistema o test funzionale) Rapporto di prova del modulo sw SMTR Validazione (Testing di Modulo) Specifica di Configurazione del sw (259) RILASCIO

DOCUMENTAZIONE PROCESSO La documentazione è così completa solo nel caso di alcune commesse per le quali si effettuano anche dei particolari test di modulo-modello, per le altre commesse non si fanno test di modulo e non esiste una documentazione di dettaglio. Per alcune commesse mancano una parte dei documenti elencati, in particolare le Specifiche di test e i relativi report, in questi casi concludiamo che non esiste una test-procedure formalizzata. Anche per la progettazione del CC non esiste una procedura di validazione documentata. Il documento SFD in alcuni casi è un documento in ingresso per i progettisti, in altri casi è un documento in uscita. NOTA: per informazioni sulla documentazione specifica di ogni commessa vedi file Excel in allegato.

Strumenti software adottati Codifica con MATLAB oppure linguaggio di programmazione C. Ambiente di simulazione e di integrazione : Microvision di IDE Suite di tool: KEIL Loader e Terminal Per i test funzionali: test in Labview Nuovi tool sw: CVS, SVN, JIRA Questi strumenti sono usati per 2 commesse.

Strumenti software adottati In alcuni casi per i test funzionali viene utilizzato il nuovo tool SALOME’. Per alcune commesse non si utilizzano Matlab, né Test in Labview. NOTA: per informazioni dettagliate per commessa relative agli strumenti sw adottati compresi i tool sw introdotti dal gruppo V&V, vedi monitoraggio in allegato.

PROCESSO PROGETTAZIONE CCA le fasi

PRESENZA DI CICLI ANALISI DEI REQUISITI FUNZIONALI E VERIFICA DI FATTIBILITA’ DEFINIZIONE REQUISITI FUNZIONALI DI VEICOLO TEST DI INTEGRAZIONE SU PC, IN LABORATORIO, IN SALA PROVE IMPLEMENTAZIONE O PROGETTAZIONE PROGETTAZIONE O ARCHITETTURA DI SISTEMA TEST DI INTEGRAZIONE DEL SW SULLA MACCHINA

DOCUMENTAZIONE PROCESSO IN INGRESSOIN USCITAFASE CORRISPONDENTE CAPITOLATISpecifica dei Requisiti del sw SRS (253) Progettazione di Massima Specifica dei requisiti funzionali di veicolo SFD Specifica di Prova dei requisiti del sw o Specifica di test del sw STS (258) Progettazione di Massima Requisiti RAMSDescrizione del sw SDD (252)Progettazione di Massima Piano di Assicurazione della Qualità del sw Descrizione di dettaglio del sw DSDD Progettazione di Dettaglio Manuale di CodificaCODICE SORGENTECODIFICA Rapporto di prova del sw o SW Test Report STR (257) Validazione (Testing di Sistema o test funzionale) Specifica di configurazione del sw (259) RILASCIO

DOCUMENTAZIONE PROCESSO Questo schema riassuntivo riguarda la documentazione più completa relativa solo a qualche commessa. per alcune commesse mancano i Test Report. Per la maggior parte delle commesse mancano i documenti di SRS e i documenti di SFD quasi sempre non sono forniti dai sistemisti, ma sono costituiti da documenti già redatti in passato e riutilizzati, apportando le opportune modifiche; inoltre la documentazione relativa ai test è estremamente scarsa e sommaria.

PROCESSO VALIDAZIONE CCA per 2 commesse (I gruppo) DOPPIO PROCESSORE Integrazione SW-SW SIMULAZIONE SU PC Integrazione SW-HW Test della scheda LABORATORIO INTEGRAZIONE CESTELLO COMPLETO LABORATORIO COMBINED TEST SALA PROVE SINGOLO PROCESSORE Le prime due fasi sono sostituite da una procedura effettuata con il tool XTest, “antenato” del tool Salomè, ed utilizzato solo dai progettisti CCA di queste due commesse, che sono intenzionati a sostituirlo con il nuovo tool sw.

PROCESSO VALIDAZIONE CCA per tutte le altre commesse (II gruppo) SIMULAZIONE PC TEST SU SCHEDA DI CONTROLLO ISOLATA TEST SU CESTELLO ISOLATO TEST DELL’ AZIONAMENTO COMPLETO

Strumenti software adottati Ambiente BORLAND MATLAB Terminal Loader ARAXIS JIRA,CVS,SVN,CONFLUENCE,DOXYGEN

PROCESSO PROGETTAZIONE CD le fasi

PRESENZA DI CICLI ANALISI DEI REQUISITI FUNZIONALI E VERIFICA DI FATTIBILITA’ DEFINIZIONE REQUISITI FUNZIONALI DI VEICOLO TEST DI INTEGRAZIONE SU PC, IN LABORATORIO IMPLEMENTAZIONE O PROGETTAZIONE PROGETTAZIONE O ARCHITETTURA DI SISTEMA TEST DI INTEGRAZIONE DEL SW SULLA MACCHINA

DOCUMENTAZIONE PROCESSO IN INGRESSOIN USCITAFASE CORRISPONDENTE CAPITOLATISpecifica dei requisiti funzionali di veicolo SFDD Progettazione di Sistema PROTOCOLLI DI DATOSpecifica dei Requisiti del sw SRS (253) Progettazione di Massima DOCUMENTO DI TRAFFICO DATI Specifica di Prova dei requisiti del sw o Specifica di test del sw STS (258) Progettazione di Massima Descrizione del sw SDD (252) DIS (disegno di insieme del sw) Progettazione di Massima Specifica di Generazione del sw (256) documento di factoring Progettazione di Massima CODICE SORGENTECODIFICA Rapporto di prova del sw o SW Test Report STR (257) Validazione (Testing di Sistema o test funzionale) Specifica di configurazione del sw (259) RILASCIO DIZIONARIO DIAGNOSTICO DI BORDORILASCIO PROCEDURE DI CARICAMENTORILASCIO

Strumenti software adottati per alcune commesse Linguaggio di programmazione C Compilatore/linker WATCOM 10.6 Costruttore grafico QNX AppBuilder JIRA, CVS, SVN Suite di tool per i test : tool1: serve per fare i back up e gestire la configurazione durante l’intero ciclo di vita del sw. tool2: serve per agevolare il colloquio con il dispositivo di laboratorio via telnet. tool3: serve a generare le maschere di segnale logico a partire dalle pseudovariabili legate ad uno dei bus.

Strumenti software adottati per le altre commesse Terminal e Loader JIRA, CVS, SVN, CONFLUENCE Sistema operativo: Windows XP embedded Ambiente di sviluppo software: DELPHY

GLI STEP DELLA VALIDAZIONE LABORATORIO PC-LABORATORIO-SALA PROVE PC-LABORATORIO VEICOLOVEICOLO Per il SISTEMA INTEGRATO l’assenza di realizzazione dei test in sala prove contribuisce in maniera significativa alla presenza di errori rinvenuti dai test sul veicolo.

LIMITI DEL PROCESSO Non sono effettivamente considerati i requisiti di qualità e di sicurezza. Non esiste una chiara distinzione di competenze tra progettisti e sistemisti: i documenti di Specifica dei Requisiti di Sistema e dei Requisiti del Software sono redatti in alcuni casi esclusivamente dai progettisti, in altri casi solo dai sistemisti, in altri casi ancora sono frutto di un lavoro di collaborazione tra progettisti e sistemisti; spesso sono ottenuti mediante un riuso di documenti realizzati in passato. Il documento SFD di solito è incompleto e poco dettagliato: ciò implica frequenti interventi del cliente e continue modifiche correttive.

LIMITI DEL PROCESSO Documentazione incompleta, e contenuti di Documenti diversi spesso accorpati in un documento unico. La realizzazione della documentazione del sw non è considerata parte integrante delle attività di processo e strumento di progettazione, ma un’attività facoltativa, spesso non realizzata per mancanza di tempo. Per la maggior parte delle commesse non esiste una test-procedure formalizzata (processo di validazione standard). Mancano ambienti di simulazione più vicini alla realtà. Non esistono delle attività di verifica: le DR non si svolgono alla fine di ogni fase, ma sporadicamente e non vengono formalizzate.

LIMITI DEL PROCESSO I progettisti lavorano su tutte le fasi del processo, in particolare si occupano anche della realizzazione dei test di validazione e delle attività di manutenzione (spiccato TURN- OVER delle risorse sui progetti), ne deriva un sovraccarico di lavoro e di responsabilità a cui non corrisponde un adeguato ritorno in termini economici. E’ evidente la presenza di una sovrapposizione di ruoli.

LIMITI DEL PROCESSO assenza di condivisione di metodologie lavorative

LIMITI DEL PROCESSO Scarsa comunicazione tra i progettisti e mancanza di flusso informativo tra i vari team di lavoro nell’ambito del processo sw. Una maggiore condivisione delle informazioni consentirebbe una più efficiente risoluzione di problemi già risolti su progetti simili. Mancanza di omogeneità nelle procedure di lavoro e utilizzo di differenti risorse strumentali.

LIMITI DEL PROCESSO Scarsa diffusione dei nuovi tools software proposti dai progettisti della V&V. Differente atteggiamento, in alcuni casi indifferenza o scetticismo, nei confronti di innovazioni volte al miglioramento del processo.

LIMITI DEL PROCESSO Mancanza di una pianificazione delle attività e di un Sistema di Monitoraggio e Controllo delle prestazioni di processo. Mancanza di procedure per la gestione delle modifiche sw. Mancanza di Gestione del RIUSO DEL SW mediante condivisione dei moduli di libreria, a discapito dell’efficienza della progettazione. Le tecniche di riuso del software sono volte a garantire una maggiore “robustezza” del sw (capacità del sw di reagire bene a stimoli anomali, anche in casi non esplicitamente previsti nei requisiti).