processi di certificazione e certificazione del …tullio/cs/dispense_2006/s3-4.pdfpadova, iii...
Post on 15-Feb-2019
232 Views
Preview:
TRANSCRIPT
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”
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
33
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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à
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
44
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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)
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
55
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
Ciclo di vita – modello sequenziale (a cascata)
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
66
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
Ciclo di vita – modelli incrementali
Analisi ed architettura non sono ripetute
Viene ripetuto l’intero sviluppo
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
77
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
Ciclo di vita – modello a spirale
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
88
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
99
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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 -
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1010
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1111
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1212
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1313
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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”
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1414
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1515
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1616
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1717
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
Sviluppo - Tracciabilità dei requisiti : un esempio
Vol2REQ_to_SubSYSREQ.pdf
Vol2REQ_nontracciati_SubSYSREQ.pdf
SubSYSREQ_to_Documents.pdf
SubSYSTestStep.doc
SubSYSTest_Procedure.pdf
DB
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1818
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
1919
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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à
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2020
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2121
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2222
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2323
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2424
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2525
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2626
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2727
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2828
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
2929
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
Gestione non-conformità
VerificaVerifica
ValidazioneValidazione
Non ConformitàNon Conformità
AnalisiAnalisi
SpecificaSpecifica
ProgettoProgetto
RealizzazioneRealizzazione
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3030
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3131
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3232
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3333
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3434
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3535
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3636
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3737
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3838
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
3939
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
4040
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
4141
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
4242
Processi di sviluppo per il SoftwareProcessi di sviluppo per il Software
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
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 prodottoProcessi di sviluppo di prodotto
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
4545
Processi di sviluppo di prodottoProcessi di sviluppo di prodotto
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
4646
Processi di sviluppo di prodottoProcessi di sviluppo di prodotto
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
4747
Processi di sviluppo di prodottoProcessi di sviluppo di prodotto
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
4848
Processi di sviluppo di prodottoProcessi di sviluppo di prodotto
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
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
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: Sales@ValidatedSoftware.com Sales Office: 650-712-0655
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
5151
Certificazione FunzionaleCertificazione Funzionale
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
5252
Certificazione FunzionaleCertificazione Funzionale
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
5353
Certificazione FunzionaleCertificazione Funzionale
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
5454
Certificazione FunzionaleCertificazione Funzionale
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
5555
Certificazione FunzionaleCertificazione Funzionale
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
5656
Certificazione FunzionaleCertificazione Funzionale
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.
Padova, III Trimestre Padova, III Trimestre Anno Accademico 2005/6Anno Accademico 2005/6
Esperienze dai sistemi di segnalamento Esperienze dai sistemi di segnalamento ferroviariferroviari
5757
Certificazione FunzionaleCertificazione Funzionale
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.
top related