Processi di Certificazione e Certificazione del …tullio/CS/Dispense_2006/S3-4.pdfPadova, III...

Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6

Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari

11

Processi di Certificazione e Processi di Certificazione e

Certificazione del SoftwareCertificazione del Software

� 26 – 27 Gennaio 2005�� Presentazione relatore e aziendaPresentazione relatore e azienda

�� Definizione di Certificazione e ruoli Definizione di Certificazione e ruoli

�� Cosa si certificaCosa si certifica�� Qualità Qualità –– Processo Processo -- ProdottoProdotto

�� Chi certifica Chi certifica –– chi accreditachi accredita�� Enti Internazionali, Enti EuropeiEnti Internazionali, Enti Europei

�� La Certificazione del SoftwareLa Certificazione del Software

�� Misurare la Qualità del SoftwareMisurare la Qualità del Software

� 2 – 3 Marzo 2005�� Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software

�� Processi di sviluppo di ProdottoProcessi di sviluppo di Prodotto

�� Software “certificabile”Software “certificabile”



22

Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software

Migliorare il processo per migliorare il prodotto

� Migliorare la qualità e la produttività agendo sul processo piuttosto che sul prodotto. Si focalizza su:

�� Definizione dei processiDefinizione dei processi�� ProcedureProcedure

�� MetodiMetodi�� StrumentiStrumenti

�� Controllo tramite misureControllo tramite misure

� Standard di riferimento : ISO 12207:1995 – Software life cycle processes



33


I processi ISO 12207

Processi organizzativi

Processi di SupportoProcessi Primari

Gestione

Miglioramento

Infrastruttura

Addestramento

Assicurazione Qualità

Ispezioni

Verifica

Validazione

RiesamiSviluppo

Accettazione/Operazione

Manutenzione

Acquisizione Documentazione

Gestione ConfigurazioneFornitura

ISO 12207 definisceISO 12207 definiscei processi, ma non i processi, ma non il ciclo il ciclo di vitadi vita come successionecome successione

di di fasifasi

Gestione Non-Conformità



44


Processi e Fasi

� Processo: Una pianificata serie di azioni al fine di produrre unrisultato. Un processo ha sempre un input ed un out put

� Fase: insieme di processi allocati nel tempo (piani ficati).

Ore di lavoro

Tempo

Fase

Processo (si svolge completamente in una fase)

Processo (si svolge a cavallo di più fasi)



55


Ciclo di vita – modello sequenziale (a cascata)



66


Ciclo di vita – modelli incrementali

Analisi ed architettura non sono ripetute

Viene ripetuto l’intero sviluppo



77


Ciclo di vita – modello a spirale



88


Ciclo di vita – modello a “V”

Architettura Software

Progettazione dei Moduli Software

Test dei Moduli Software

Codifica

Integrazione del Software

Integrazione Software/Hardware

Validazione del Software

Accettazionedel Software

Manutenzione del Software

Specifica dei Requisiti Software

Sviluppo del Sistema



99


Gestione del progetto

� Scopo: Assicura che il progetto consegni il prodott o in tempo, nel budget previsto e con la qualita’ richiesta.

PIANIFICAZIONE

SVILUPPO

Rapporti

Requisiti

Prodotti

StandardsPiani

- Management Control Loop -



1010


Gestione del progetto - Strumenti

� WBS (Work Breakdown Structure): definisce la strutt ura e decomposizione del lavoro da svolgere

� Organigramma: definisce la struttura e l’allocazione delle risorse al progetto

� Gannt (barchart): rappresenta graficamente il piano , evidenziando l’allocazione nel tempo e la durata dei task

� CPM/PERT(Critical Path Method/Program Evaluation Re view Technique): rappresenta graficamente il piano, evid enziando le dipendenze tra le attività ed il loro impatto sull’i ntero progetto.



1111


Gestione del progetto - Pianificazione

� Attività gestionale che attraversa tutto il ciclo di vita� Produzione e aggiornamento dei piani

�� Piano di SviluppoPiano di Sviluppo SoftwareSoftware

�� Piano di Assicurazione della Qualità del Piano di Assicurazione della Qualità del SoftwareSoftware

�� Piano di Gestione della Configurazione del Piano di Gestione della Configurazione del SoftwareSoftware

�� Piano della Documentazione del SoftwarePiano della Documentazione del Software

�� Piano di Piano di VerificaVerifica SoftwareSoftware

�� Piano di Piano di ValidaValida zzionion ee SoftwareSoftware

�� Piano di Manutenzione Piano di Manutenzione SoftwareSoftware

�� Standard di codifica applicabiliStandard di codifica applicabili



1212


Infrastruttura – Miglioramento - Addestramento

In generale rientrano nei processi a livello aziend ale di Gestione della Logistica, gestione della Qualità e gestione delle Risorse

� Valutazione e Sorveglianza dei Fornitori� Gestione degli approvvigionamenti� Controllo in entrata e Gestione Magazzino� Gestione offerte e Ordini da Clienti� Gestione delle attività di Progettazione� Gestione e controllo della Produzione� Gestione e controllo dell’Assistenza� Verifiche ispettive interne� Gestione delle non conformità� Azioni Correttive, Preventive e di Miglioramento� Sviluppo delle risorse umane� Gestione strumenti



1313


Acquisizione

� include le attività eseguite dal cliente. In partic olare:-- la definizione dei requisiti del sistema;la definizione dei requisiti del sistema;-- la preparazione ed emissione della richiesta di offerta;la preparazione ed emissione della richiesta di offerta;-- la preparazione del contratto;la preparazione del contratto;-- selezione e controllo del fornitore;selezione e controllo del fornitore;-- accettazione del prodotto finale.accettazione del prodotto finale.

Nota: il concetto di Nota: il concetto di clientecliente è distinto da quello dell’è distinto da quello dell’utente. utente. Quest’Quest’ultimo è responsabile del processo “operazione”ultimo è responsabile del processo “operazione”



1414


Fornitura

� include le attività relative al fornitore. In parti colare:�� la preparazione dell’offerta e del contratto; la preparazione dell’offerta e del contratto;

�� la pianificazione, esecuzione e controllo del progetto; la pianificazione, esecuzione e controllo del progetto;

�� la revisione del prodotto;la revisione del prodotto;

�� la sua consegna al cliente ;la sua consegna al cliente ;

�� (eventualmente) la messa in servizio;(eventualmente) la messa in servizio;

�� (eventualmente) la manutenzione evolutiva(eventualmente) la manutenzione evolutiva



1515


Sviluppo

�� Definizione ed implementazione del processoDefinizione ed implementazione del processo�� Analisi dei requisiti di sistemaAnalisi dei requisiti di sistema�� Progettazione dell’architettura del sistemaProgettazione dell’architettura del sistema�� Specifica dei requisiti softwareSpecifica dei requisiti software�� Progettazione dell’architettura del softwareProgettazione dell’architettura del software�� Progettazione dettagliata del softwareProgettazione dettagliata del software�� Codifica e test del softwareCodifica e test del software�� Integrazione del software (Integrazione del software ( Sw+SwSw+Sw ))�� Accettazione del softwareAccettazione del software�� Integrazione del sistema (Hw+Sw)Integrazione del sistema (Hw+Sw)�� Qualificazione del sistemaQualificazione del sistema�� Istallazione del sistemaIstallazione del sistema



1616


Sviluppo - Specifica dei Requisiti del Software

� I requisiti software sono composti da:

�� una parte testuale che descrive i requisiti (gli standard definuna parte testuale che descrive i requisiti (gli standard definiscono iscono diversi tipi di requisiti)diversi tipi di requisiti)

�� un modello logico dei requisiti, generalmente un un modello logico dei requisiti, generalmente un Modello semiModello semi--formale (e.g. UML, OMT, FSM, DFD, SDL)formale (e.g. UML, OMT, FSM, DFD, SDL)

� I Requisiti devono essere precisi, non ambigui, completi, testabili

� I requisiti del Software sono derivano dai Requisit i del sistema

� La tracciatura dei Requisiti nel processo di proget to e sviluppo è fondamentale per la buona riuscita

� Dalla specifica dei Requisiti del software deriva:

� Specifica dei Test dei Requisiti del Software => per la Validazione



1717


Sviluppo - Tracciabilità dei requisiti : un esempio

Vol2REQ_to_SubSYSREQ.pdf

Vol2REQ_nontracciati_SubSYSREQ.pdf

SubSYSREQ_to_Documents.pdf

SubSYSTestStep.doc

SubSYSTest_Procedure.pdf

DB



1818


Sviluppo - Architettura del Software

� Progettazione architetturale:�� L’architettura definisce la struttura ad alto livello che identiL’architettura definisce la struttura ad alto livello che identifica le fica le

ComponentiComponenti software. software.

�� Sono definite le interfacce verso il mondo esterno e tra le compSono definite le interfacce verso il mondo esterno e tra le componentionenti

�� Sono definiti metodi, tecniche e strumenti di sviluppo del softSono definiti metodi, tecniche e strumenti di sviluppo del softwareware

�� I Requisiti del Software diventano Requisiti di Componente, con I Requisiti del Software diventano Requisiti di Componente, con un un maggior livello di dettagliomaggior livello di dettaglio

�� Deve essere condotto un riesame per finalizzare l’architetturaDeve essere condotto un riesame per finalizzare l’architettura

�Dalla specifica dei Requisiti delle Componenti soft ware derivano i Pianidi:

� Test di Integrazione del Software => Verifica

� Test di Integrazione Hardware/Software => Verifica



1919


Sviluppo - Architettura del Software : un esempio

BootBoot

NominaleNominale TestTest

Board Support PackageBoard Support Package

ProtocolloProtocollo

DownloadDownload

Sistema Sistema

OperativoOperativo

CRITERI :� Allocazione di ciascuna

Funzione principale ad una stessa componente: modularità, localizzazione

� Individuazione software riusabile: Sistema Operativo e Protocollo

� Assegnamento lineare dei Requisiti

� Interfacce minime, che specificano servizi omogenei tra loro: astrazione, information-hiding

� No variabili globali� Relazioni client/server� Localizzazione interfacce

hardware software per facilitare re-targeting

� Stesso livello di integrità



2020


Sviluppo - Progettazione dettagliata del software

� Ogni Componente viene ulteriormente scomposta fino ad arrivare al livello di Modulo

� Un Modulo software coincide generalmente con un sin golo file sorgente� Per ogni Modulo si dovrebbe avere un documento di p rogetto

autoconsistente



2121


Sviluppo - Progettazione dettagliata del software – un esempio di notazione

P_Op1P_Op2P_Op3

T

Parent_ObjectT

C_OBJ1

C1_Op1C1_Op2

T C_OBJ2

C2_Op1C2_Op2

use relationship

implemented-by relationship

U_OBJ11

U_OBJ2



2222


Sviluppo - Codifica del Software

� Ciascun Modulo software e’ implementato in conformi tà al documento di progetto di dettaglio

� Applicazione del Piano di Sviluppo del Software

� Applicazione della Architettura del Software

� Applicazione degli Standard di Codifica

� Applicazione della Gestione della Configurazione de l Software



2323


Sviluppo - Integrazione del software

� Integrazione�� Le unità sono assemblate generalmente in modo“Le unità sono assemblate generalmente in modo“bottombottom--upup”, prima a livello ”, prima a livello

di Modulo per ottenere le Componenti finite, in seguito per intedi Modulo per ottenere le Componenti finite, in seguito per integrazione grazione delle Componentidelle Componenti

�� È opportuna una attività preliminare di test da parte degli svilÈ opportuna una attività preliminare di test da parte degli sviluppatori, sia a uppatori, sia a livello di modulo che di componente prima di sottoporre il softwlivello di modulo che di componente prima di sottoporre il software a test più are a test più formali di Verificaformali di Verifica

�� I risultati ottenuti sono soggetti ad un’attività di riesameI risultati ottenuti sono soggetti ad un’attività di riesame

� Accettazione�� Avviene sul prodotto integrato e verifica che ciascun requisito Avviene sul prodotto integrato e verifica che ciascun requisito sia sia

implementatoimplementato

�� I risultati ottenuti sono soggetti ad un’attività di Audit globaI risultati ottenuti sono soggetti ad un’attività di Audit globale che verifichi il le che verifichi il prodotto ed i processi eseguiti con la relativa documentazioneprodotto ed i processi eseguiti con la relativa documentazione



2424


Accettazione e Operazione

� L’accettazione finale coinvolge anche il Cliente� Si basa sui risultati della Verifica e Validazione� L’accettazione finale del software deve avvenire ne l suo ambiente finale.� Un’accettazione parziale del software può avvenire prima dell’integrazione

finale (spesso l’ambiente finale e’ disponibile sol o dal cliente)� In alcuni casi l’accettazione finale e’ legata alla scadenza della garanzia.

La garanzia e’ dimensionata in modo da avere il sof tware in operazione per un ragionevole lasso di tempo



2525


Manutenzione� Correttiva (20%) : risoluzione degli errori sia nel codice che nella

documentazione

� Adattativa (20%): cambi dovuti a variazione dell’am biente operativo esterno

� Perfettiva (50%): cambi dovuti a miglioramenti rich iesti dal cliente

� Preventiva (10%): rendere più semplice l’individuaz ione degli errori tramite miglioramenti del codice (ristrutturazione, pulizia , ecc.)

Occorre un Piano Manutenzione del Software con procedure per:� Controllo degli errori

� Raccolta degli errori� Configurazione Software / di Sistema

� Definizione dell’Autorità che approva i cambiamenti

� Verifica, Validazione e Approvazione del Software modificato



2626


Gestione Configurazione

� Un elemento della configurazione (Configuration Item – CI) e’ un aggregazione del Software identificato come unita’ d i configurazione. Un CI puo’ includere altri CI a piu’ basso livello (de composizione gerarchica).

� Attivita’ di Gestione della Configurazione:�� identificazione della configurazioneidentificazione della configurazione (Cosa, Come e (Cosa, Come e Perche’Perche’))

�� identificazione del supporto fisicoidentificazione del supporto fisico (Dove)(Dove)

�� controllo di configurazionecontrollo di configurazione (Chi fa cosa)(Chi fa cosa)

�� mantenimento dello stato di configurazionemantenimento dello stato di configurazione

�� gestione delle release e delle consegnegestione delle release e delle consegne

� Include anche tutto l’ambiente utilizzato nel ciclo di vita�� file di configurazionefile di configurazione�� compilatoricompilatori�� assemblatoriassemblatori



2727


Gestione della Documentazione

� I documenti da produrre devono essere strutturati in modo da poter essere integrati in parallelo con le fasi di sviluppo

� Deve essere prevista la tracciabilità dei documenti

� riferimenti

� relazioni

� terminologia

� Se sono diversi dai documenti standard del Cliente occorre una tabella di riferimento incrociata per i documenti da produrre.



2828


Gestione della Documentazione – un esempio

Piano di Assessment.pdf

TracciabilitàDocsRFIDocsECM.pdf

Dipendenze versioni ONLINE.pdf

TutteVersioni.pdf

Stato Documentazione.pdf

Stato Documentazione ONLINE.pdf



2929


Gestione non-conformità

VerificaVerifica

ValidazioneValidazione

Non ConformitàNon Conformità

AnalisiAnalisi

SpecificaSpecifica

ProgettoProgetto

RealizzazioneRealizzazione



3030


Archivio delle non-conformità

ArchivioAnomalie

Piano dei Test diSistema(iniziale)

Sistemamodificato?

Esecuzionecampagna di

test di sistema(totale)

Rapporto di test disistema(iniziale)

NO NO

NO

SI

SI

SI

Aggiornamentoprocedure di test

di sistema

Esecuzionecampagna di

test di sistema(parziale)

Anomalieaperte?

Piano dei Test diSistema

(corrente)

Gestioneanomalie

Rapporto di test disistema

(corrente)

Requisiti disistema

modificati?

Aggiornamentospecifiche di test di

sistema

Anomalie

in altre fasi?

SI

FINE NO

� L’archivio viene popolato dalle non conformità generate dalla Verifica e dai Test

� Ad un certo istante dello sviluppo tutti i processi di test sono attivi

� La gestione di ogni non-conformità può causare modifiche del codice

� Ogni modifica ha un impatto sui processi di test per dimostrare la non regressione

� Senza una efficace pianificazione, la gestione delle non-conformità può causare un notevole aumento di tempi e costi di sviluppo



3131


Definizioni VerificaAttività di determinazione, attraverso analisi e test, che l‘output di ciascuna fase del ciclo-di-vita soddisfa i requisiti della fase precedente.

ValidazioneConferma ottenuta per mezzo di esame o fornendo l‘evidenza obiettiva che il software soddisfa tutti i requisiti per esso specificati per l‘uso designato

AccettazioneRisultato della fase di validazione, cioè dimostrazione che il (sotto)sistema software soddisfa tutti i suoi requisiti per la specifica applicazione



3232


Verifica e Test

Fase di Sviluppo del Sistema

Progettazione e Architettura Software

Progettazione dei Moduli Software

Test dei Moduli Software

Codifica

Integrazione del Software

Integrazione Software/Hardware

Validazione del Software

Accettazione del Software

Manutenzione del Software

Specifica dei Requisiti Software

Verifica

Test



3333


Verifica

Verifica Statica: analisi e revisione senza eseguire il codice �� Verifica della documentazioneVerifica della documentazione�� Verifica della tracciabilitàVerifica della tracciabilità�� Verifica delle regole di codificaVerifica delle regole di codifica�� Verifica delle metriche del codiceVerifica delle metriche del codice�� Verifica della adeguatezza dei piani di TestVerifica della adeguatezza dei piani di Test

Verifica Dinamica: il codice e’ eseguito�� Esecuzione dei Piani di TestEsecuzione dei Piani di Test�� Verifica della copertura dei testVerifica della copertura dei test



3434


Verifica statica

� Adeguatezza dei Requisiti Software nel soddisfare i requisiti della fase precedente

� Adeguatezza della Specifica dei Test dei Requisiti Software come prova dei Requisiti� Consistenza interna dei Requisiti Software

� Adeguatezza dell’Architettura e del Disegno Software nel soddisfare la Specifica dei Requisiti Software

� Consistenza e completezza della Specifica del Disegno Software rispetto ai Requisiti Software

� Adeguatezza del Piano dei Test di Integrazione come prova dell’Architettura e del Disegno Software

� Consistenza interna della Specifica dell’Architettura e del Disegno Software

� Conformità rispetto alla Specifica del Disegno di Modulo Software

� Conformità rispetto al piano di qualità

� Corretta applicazione degli standard di programmazione



3535


Verifica dinamica

� Suddivisa su diversi livelli di Test�� Test di ModuloTest di Modulo

�� Test di integrazione SoftwareTest di integrazione Software

�� Test di integrazione Hardware/SoftwareTest di integrazione Hardware/Software

� Casi di test e dati di test � Tipi di test da eseguire� Metodi e strumenti di test � Ambiente di test, strumenti, configurazioni e programmi� Criteri di test per giudicare il completamento del test� Test ripetibili� Elementi sotto test configurabili ed identificabili



3636


Verifica dinamica – Test di Modulo

� Sono i più “vicini” al codice e possono ottenere la migliore copertura

� Ogni Modulo testato stand-alone utilizzando “stub” dei moduli che utilizza. Possibilità di “guidare” il flusso di con trollo

� Generalmente eseguiti su host con un Tool di suppor to, tipicamente CANTATA (IPL)�� Possibilità di eseguire azioni di Analisi StaticaPossibilità di eseguire azioni di Analisi Statica

�� Necessità di instrumentare il codiceNecessità di instrumentare il codice

�� Disponibili librerie per eseguire i test sul targetDisponibili librerie per eseguire i test sul target

� Critici per il tempo di definizione delle procedure di dettaglio� Critici anche per il tempo di esecuzione dei test s e questi girano

su target� Critici per il rischio di re-working per modifiche del Software



3737


Verifica dinamica – Test di Modulo – nella pratica

� A seconda del livello di criticità del software (de lla qualità desiderata) occorre dimensionare con attenzione alc uni parametri, che influiscono pesantemente su tempi e costi:�� Livello di copertura richiestoLivello di copertura richiesto

�� Utilizzo delle tecniche di “Equivalence Classes and Input PartitUtilizzo delle tecniche di “Equivalence Classes and Input Partitioning” e ioning” e “Boundary Range Analysis” “Boundary Range Analysis”

�� Metriche di riferimento per il codiceMetriche di riferimento per il codice

� Per ottimizzare questa attività spesso è preferibil e:�� Una campagna di test preliminare con pochi test funzionali, per Una campagna di test preliminare con pochi test funzionali, per utilizzare le utilizzare le

capacità di Analisi Statica del Toolcapacità di Analisi Statica del Tool

�� Una seconda campagna condotta a “blackUna seconda campagna condotta a “black--box” basandosi sulla box” basandosi sulla documentazione di progetto di dettaglio, misurando la copertura documentazione di progetto di dettaglio, misurando la copertura ottenutaottenuta

�� Una campagna condotta a “white box” per raggiungere la coperturaUna campagna condotta a “white box” per raggiungere la coperturadesideratadesiderata



3838


Verifica dinamica – Test di Integrazione Software

� Integrazione dei Moduli fino ad ottenere la Componen te funzionante, si possono avere passi intermedi di integrazione parzia le

� La Componente viene stimolata chiamando le sue oper azioni di interfaccia e verificata a fronte dei suoi Requisit i

� Il comportamento atteso non dipende solo da valori ritornati o modifiche di variabili, ma anche da azioni sull’ambiente di te st

� L’integrazione delle Componenti può avvenire in modo incrementale, partendo dalle più vicine all’hardware, modo consigliato per software embedded . L’integrazione delle Componenti in questo caso coi ncide con l’integrazione dei Moduli di Componenti di livello s empre più alto, linkando il codice effettivo delle Componenti utili zzate e già testate

� L’integrazione delle Componenti può anche avvenire, comunque, anche su host, con approccio “top-down”, utilizzando “stub” delle Componenti di più basso livello e rimandando l’integrazione har dware/software



3939


Verifica dinamica – Test di Integrazione Hardware/So ftware

� Può coincidere con i Test di Integrazione software d i una o più Componenti in cui sono concentrate le interazioni con l’hardware, mentre tutte le altre Componenti utilizzano i servizi forniti dalle prime

� Se l’interazione con l’hardware è distribuita in tut to il software, questo livello di test può diventare un’attività molto cri tica

� In ogni caso, occorrono ambienti di test capaci di stimolare l’hardware anche in casi non nominali e di monitorizzare con pre cisione il comportamento dell’hardware

� In generale, le procedure di test comprendono azioni eseguite mediante simulatori di ambiente, mentre i risultati attesi c omprendono segnali analogici o digitali rilevabili con strumenti di mi sura



4040


Validazione

La validazione può essere considerata una verifica “end-to-end”� Validazione e’ essenzialmente dinamica.� I test di validazione dimostrano che il software sod disfa tutti i requisiti

�� requisiti funzionali:requisiti funzionali:

�� casi nominalicasi nominali

�� casi non nominalicasi non nominali

�� requisiti non funzionali:requisiti non funzionali:

�� requisiti di performancerequisiti di performance

�� requisiti di efficienzarequisiti di efficienza

�� requisiti di qualitàrequisiti di qualità

� I test di validazione sono i Test dei Requisiti del Software



4141


Riesami

Riesame: un processo o meeting durante il quale un prodotto, o un insieme di prodotti, e’ presentato al personale di progetto, manager, utenti, clienti, o altre parti

interessate per commenti ed approvazione

� Analisi di Percorso: valuta uno specifico elemento software nel tentat ivo di identificare difetti e possibili soluzioni.

� Ispezioni: simili alle Analisi di Percorso, ma il fuoco e’ s ulla ricerca degli errori. Non sono identificate le soluzioni.

� Riesami tecnici valutano uno specifico elemento software per valuta re il progresso rispetto al piano

� Valutazioni: riesami indipendenti per verificare la conformità con i requisiti software, specifiche, standards, procedure, requisi ti contrattuali e di licenza.



4242


IspezioniObbiettivo: scoprire errori nel codice e nella documentazione� Fagan formalizzò la sua ispezione nel 1976 (Fagan I nspections)� Efficienza: fino al 50% degli errori scoperti trami te ispezione� Velocità d’ispezione: 120 LOC/h (C++)

Le Ispezioni sono basate su ChecklistEfficiente come verifica statica, piccolo guadagno per la verifica dinamica

Esempio di checklist�Il file non e’ chiuso in caso di terminazione da errore�Nell’ istruzione di Switch il caso di Default non e’ previsto�La copia del puntatore dovrebbe probabilmente essere la copia dell’oggetto riferito�Parti del codice non sono raggiungibili�Ci sono dei cicli infiniti�Ci sono delle ricorsioni infinite�Dovrebbe esistere un solo punto d’ingresso e di uscita�Per ciascuna variabile dichiarata:

� deve essere usata almeno una volta� deve essere inizializzata



4343

Processi di sviluppo di prodottoProcessi di sviluppo di prodotto

Fattori che concorrono al prodotto

ProdottoServizio

Diagramma a “Spina di pesce”

personale

strumentiprocessi

materiali

addestramentoaddestramento

carico di lavorocarico di lavoro

efficaciaefficacia

calibrazione

controllocontrollo

produzioneproduzione

progettazioneprogettazione

trasporto

fornitorifornitori

miglioramentomiglioramento

ambiente



4444

�� I Processi AziendaliI Processi Aziendali

� Riesame ordini� Gestione commesse� Gestione dei progetti� Progettazione� Controllo modifiche di progetto� Logistica� Qualificazione e rivalutazione fornitori� Approvvigionamenti e loro verifica� Produzione e collaudo finale� Conto lavoro e sua verifica� Definizione prodotto in conto vendita e sua verifica� Imballo e spedizione


Processi di sviluppo di prodotto – un esempio

� Installazione� Tenuta sotto controllo dei dispositivi

di misurazione e monitoraggio� Tenuta sotto controllo prodotti NC� Azioni Correttive e Preventive� Assistenza� Gestione dei resi� Riesame da parte della Direzione� Verifiche Ispettive Interne� Analisi dei dati� Gestione delle competenze� Addestramento

Rete Processi Aziendali.xls



4545


Processo di Gestione

GESTIONE DEI PROGETTI rev. 1 del 20.09.2004

N°

Procedura di riferimento

Responsabile Sicurezza e V&V (*)

Capo Progetto

Responsabile Ufficio Tecnico (UT)

Responsabile Ufficio Progettaz ione (UP)

1

Valutazione progetto con eventuali implicazioni di sicurezza ferroviaria

2 Nomina capo progetto.

3 Redazione piano di progetto.

4 Approvazione piano di progetto.

5 Valutazione stati di avanzamento.

6 Sono sufficenti semplici riallocazioni delle risorse?

PRO 04.01

7 Riemissione del piano.

8 Ripianificaz ione e informazione a gestione commesse.

9 Realizzazione

Attività

FunzioniCoinvolte

Input :Richieste di progetto

Output :Progetti

2

3

4

8

9

2

4

514

NO

SI

614

614

8

7

SI

NO

1 1 1

614

(*) Fasi applicabili solo per progetti ferroviari in sicurezza



4646


Gestione della Documentazione interna ed esternaDocumentazione esterna di riferimentoDocumentazione esterna di riferimento

Cartacei:Cartacei:••Direttive Comunità EuropeaDirettive Comunità Europea••Norme UNINorme UNI••Norme InternazionaliNorme Internazionali••Specifiche RFISpecifiche RFI••Riferimenti Normativi e Riferimenti Normativi e DocumentaliDocumentali

In Linea:In Linea:••Abbonamento sezione totale Abbonamento sezione totale delle Norme CEIdelle Norme CEI••Abbonamento alla Gazzetta Abbonamento alla Gazzetta UfficialeUfficiale



4747


Gestione della Documentazione interna ed esternaDocumentazione internaDocumentazione interna

� Manuale Assicurazione Qualità � Manuale Processi Aziendali � Procedure� Istruzioni� Moduli� Standard Aziendali� Piani Controllo Qualità � Piani Qualità di Riferimento� Piani di Gestione della Fornitura� Piani di Fabbricazione e Controllo� Cartella Prodotto / Modalità di

Montaggio� Elenco fornitori qualificati

BC -bollettini di collaudoCA - carpenteria assiemiCB - cablaggiCM - carpenteria meccanicaCS - circuito stampatoDA- disposizione apparecchiatureEB - elettrico a blocchiEC - elenco componentiEE - schema elettricoEI - elettrico interconnessioniES - elettrico schedeET - elettrico trasformatoriFI - filaturaFW – firmware per memorie o logiche programmabiliIM- imballaggioMC - modalità collaudo

MM - modalità di montaggioMN - manualiNT- nota tecnicaPM - piani di montaggioPT - programma temporaleSA - standard aziendaliSC -specifica di collaudoSI - scheda installazioneSR - serigrafiaST - specifica tecnicaSW - softwareTA - tabella assegnazioniTE - targhe e etichette VI - verifica impiantiVS - viste IS - istruzioni operative

Sistema QualitàSistema QualitàDocumenti TecniciDocumenti Tecnici

PRO05-01.doc



4848


Gestione della Documentazione interna ed esternaDocumentazione di progetto (documenti costruttivi)Documentazione di progetto (documenti costruttivi)

• schemi e disegni che dettagliano forme, quote e dimensioni• rapporti di calcolo che permettono di accertare la tenuta meccanica,

l’ambiente termico, lo stress elettrico• specifiche di prodotto che identificano le caratteristiche come la tenuta

stagna, grado IP, sicurezza, affidabilità, prestazioni • specifiche di controllo che identificano le caratteristiche da tenere in evidenza

durante la produzione ed il collaudo• distinta base che elenca i materiali e le parti da utilizzare• prescrizioni di imballo per le casse, i cartoni e le etichette • prototipi che possono essere campioni, assiemi e sottoassiemi• elaborati che dettagliano i costi della soluzione adottata e quelli associati a

possibili soluzioni alternative• prototipi• rapporti di prova

Cartella ProgettoCartella Progetto SA00014.doc



4949

Software “certificabile”Software “certificabile”

Dal sito Validated Software CorporationThe IEC 61508 Validation Suite™ for MicroC/OS-II™ (uC /OS-II) is a complete IEC certifiable package of standards, designs, source code, test code and all related documentation for Micrium’s MicroC/OS-II real-time operating system (RTOS). This Validation Suite™ is comprised of the following elements:

Safety Manual Software Requirements SpecificationSoftware Development Plan (SDP) Software Verification & Validation (V&V) PlanSoftware Code Standards Software Requirements StandardsSoftware Design Standards Software Change HistorySoftware Problem Report History Software Quality Assurance (SQA) DataSoftware Design Description Software Verification Test ProcedureSoftware Test Plan (STP) Software Unit Test ProcedureSoftware Unit Test Plan Software Unit Test ReportSoftware Integration Test Procedure Software Integration Test PlanSoftware Integration Test Report Test Results ReportAll Test Source Code and Test Scripts Software Correlation/Trace MatrixVersion Description Document (VDD)

The IEC 61508 Validation Suite™ of certifiable software and documentation is available for all levels of certification, including SIL3/SIL4 systems.In addition, Validated performs an array of complementary services to speed your project to completion, including:•Porting Serviceso Ports to new processors, semiconductor platforms and coreso Development and certification of Board Support Packages (BSPs)o Ports of legacy operating system and application software•Development of specialized Validation Suiteso Port-specific documentationExample: Design Description, Special 80x86 Protected Mode Porto Full Validation Suite™ documentation for BSPs and platform codeo Normally performed in under four months with full documentation seto COTS software componentso In-house and/or proprietary operating systems and components•Safety Agency Coordination / Audit AssistanceFor more information email us at: [email protected] Sales Office: 650-712-0655



5050

Certificazione FunzionaleCertificazione Funzionale

Dal sito AVM� AVM FRITZ!Box: ADSL Router with TÜV-tested FirewallInternet Security with

FRITZ!Box Now TÜV-Certified:Blocks Internet Threats

TÜV Rheinland: FRITZ!Box is secure against attacks from the Internet AVM's security concept passes rugged tests Internet worms have no chance FRITZ!DSL software also cited

�

AVM FRITZ!Box ensures reliable protection against attacks from th e Internet . This was the conclusion reached by the engineerin g safety institute TÜV Rheinland after a thorough study. The test report is further confirmation of the standard security concept imple mented in products by the Berlin communications specialist AVM. The firewall certified by TÜV Rheinland is incorporated in all of AVM's FRITZ!Box and FRITZ !Card DSL products. The firewall is up and running, with stat eful packet inspection, IP masquerading and port forwarding, as soon as the product has been installed. The initial default settings block all s ecurity-sensitive ports, so that Internet worms such as Lovsan, Blaster, Sasser and Netsky haven't a chance.



5151


Source: Heartlab, Inc. da Press Release internet page� Heartlab's Encompass Results Management Software Certified by the American College of

Cardiology FoundationMonday January 10, 2:33 pm ET Streamlines collection of patient data for participants in national registry

� WESTERLY, R.I.--(BUSINESS WIRE)--Jan. 10, 2005-- Hea rtlab, Inc., today announced that its Encompass Results Management Version 2.04 has achie ved ACC-NCDR CL v3.0 certification . The American College of Cardiology Foundation (ACCF ) concluded a rigorous review of the Heartlab application, verifying that it meets stric t data collection standards and export requirements. As a vendor of ACC-NCDR CL v3.0 certi fied software, Heartlab provides its customers with a simple, efficient means to collect data required for participating in the National Cardiovascular Data Registry. The ACC-NCDR is a repository for information collected from cardiology catheterization labs nati onwide. The organization provides quarterly institutional reports containing national and peer group statistics relating to diagnostic and interventional procedures performed in the cath lab. These institutional reports contain key performance indicators relating to patient demographics, history/risk factors, cardiac status, treated lesions, intracoro nary device utilization and adverse outcomes. The registry consists of data from more t han 500 institutions and over 1.6 million patient discharges. The data collected focuses on o utcomes rather than on volume alone and forms the basis of benchmark comparisons among hosp itals, making it possible to assess the quality of cardiac care patients receive nation wide. Participation in the NCDR helps hospitals measure performance and improve quality o f care.



5252


Dal sito internet di American College of Cardiology� ACC-NCDR™� The ACC National Cardiovascular Data Registry Enrolls Over 300 Participants

by Ralph Brindis, MD, MPH, FACC� The demand for accurate data in the field of medicine and in particular cardiovascular

disease has been thrust upon us. Hospitals, payers, and governmental agencies are demanding accurate data related to health care operations. The opportunity for the ACC and its members to set definitive standards governing quality of data is obvious, particularly to any of us who have had the opportunity to visit the various health-related websites reporting of the "quality of care" given at various institutions. A cardiologist may find his institution rated at a mediocre level at one website while at another website the same institution may be rated higher. Different healthcare evaluation websites may use very different and arbitrary criteria to create their "report cards."

� By participating in the ACC National Cardiovascular Registry (ACC-NCDR™ )hospitals can have and therefore offer truly accurate data to use for internal benchmarking, peer hospital benchmarking and national benchmarking. Until the formation of the ACC-NCDR™ , there was an absence of standardized catheterization laboratory data. Existing data collection mechanisms were of questionable quality. Therefore, the formation of the ACC-NCDR™ seemed to be an appropriate role for the ACC. The Registry was founded based on the need for cardiovascular specialists to respond to the demands of objective assessment of outcomes of care. After a 9-year period of dataset development the ACC-NCDR™ began operations in late 1998.



5353


Dal sito CommsDesign

3Com certifiesCrystalVoice VoIP softwaregen 11, 2005 (3:16 PM)

WAYNE, N.J. — CrystalVoice landed a big vote of support for its voice-over-IP (VoIP) software, with 3Comannouncing Tuesday (Jan. 11) that it has certified CrystalVoice's softwarefor its VCX IP telephony platform. Unlike its competitors, which have simply developed SIP endpoints, CrystalVoice has developed a software offering that resides on both ends of a VoIP link, thus allowing carriers to set up private networks between servers and endpoints. In essence, the software is embedded at the client device and in a server at the host network. These software packages then continually communicate during a session to account for impairments in the IP network, such as packet loss and jitter. According to 3Com, CrystalVoice has met the interoperability testing requirementsof the 3Com Voice Solution Providers Program (VSPP). This certification confirms that CrystalVoice's VoIP software solutions are fully compatible with the 3Com VCX IP Telephony module. The software was also previously certified for 3Com's NBX IP telephony platform.



5454


Dal sito di 3Com – Servizi Professionali

� Assessment Services

� Assessment services use sophisticated test equipmen t and advanced monitoring techniques to provide the data needed to make critical network decisions. All asse ssments include a full report of actual performance statist ics, a complete analysis, and detailed recommendations.



5555


Dal sito 3Com - prodotti

� 3Com® VCX™ IP Telephony Module—the Leading SIP-PBX

� The 3Com® VCX™ IP Telephony module is one of a serie s of applications in the 3Com Convergence Applications Suite designed to help companies eliminate the boundaries of time and distance. The software suite is built around a simple idea—telephony is an enterprise app lication, critical to delivering an advanced portfolio of real-time telep hony, presence, messaging, and conferencing services to users anywh ere in the world, within a common framework of call control, authenti cation, privacy, location, and presence management services.



5656


Dal sito 3Com - prodotti

� VoIP Has Evolved Into a Significant Advantage in Enterpr ise Communications

� "Internet Voice, also known as Voice over Internet Protocol (VoIP), is a technology that allows you to make telephone calls using a broadband Internet connection instead of a regular (or analog ) phone line."

� IP is a packet technology, so the analog waves of o ur spoken words are converted to digital signals and then packetized. P ackets are sent over the IP network to the end point for reassembly and conv ersion to sound.

� For starters, VoIP has had to signal intent to deli ver voice communication in the way users expect by making the telephone rin g. Then, once the call is accepted and service performance parameters are negotiated (security, billing, quality, recording, and other options for example), the VoIP infrastructure delivers an intelligible audio strea m across the IP network.



5757


Dal sito 3Com – News

� 3Com and CrystalVoice Team to Provide Voice over In ternet Communications Solutions CrystalVoice Joins 3Com VoIP Solution Provider Prog ram as A 3ComApproved Participant Delivering Internet Voice Comm unications Solutions For 3Com Business Telephone SolutionsMarlborough, Mass., and Santa Barbara, Calif., May 12, 2004 — 3Com Corporation (NASDAQ: COMS) today announced that CrystalVoice Co mmunications, Inc. (www.crystalvoice.com), a leading provider of enter prise Internet protocol (IP) voice communications software solutions, has joined the 3Com Voice over Internet Protocol (VoIP) Solution Provider Program (VSPP).

� Under the terms of the program agreement, CrystalVo ice is named a "3Com Approved" participant, the top tier in the 3Com VSP P. This "3Com Approved" level, by invitation only, is awarded to companies whose products are commercially deployed, rigorously tested and approv ed by 3Com. CrystalVoice is also approved to sell its software through 3Com' s channel of authorized VoIP resellers. The VSPP has been created by 3Com t o meet reseller sales demand that requires unique collaboration with appl ication developers.

Processi di Certificazione e Certificazione del …tullio/CS/Dispense_2006/S3-4.pdfPadova, III...

Documents

Transcript of Processi di Certificazione e Certificazione del …tullio/CS/Dispense_2006/S3-4.pdfPadova, III...