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

Presentazione sul tema: "”OSSERVAZIONE”: l’esplorazione del processo. ELENCO DELLE PERSONE CHE HANNO COLLABORATO ALLA RICOSTRUZIONE DEL PROCESSO REALE CSCCACCCDCAV&VPE LEADER."— Transcript della presentazione:

1 ”OSSERVAZIONE”: l’esplorazione del processo

2 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

3 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.

4 NUOVI TOOL SW

5

6

7 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.

8 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.

9 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

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

11 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.

12 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

13 PROCESSO PROGETTAZIONE CS le fasi

14 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

15 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

16 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.

17 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.

18 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.

19 PROCESSO PROGETTAZIONE CCA le fasi

20 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

21 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

22 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.

23 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.

24 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

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

26 PROCESSO PROGETTAZIONE CD le fasi

27 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

28 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

29 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.

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

31 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.

32 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.

33 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.

34 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.

35 LIMITI DEL PROCESSO assenza di condivisione di metodologie lavorative

36 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.

37 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.

38 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).