![\"Conformit\u00e0](\"https:\/\/www.m-q.ch\/wp-content\/uploads\/2021\/02\/Compliance-im-Engineering.jpg\")
<\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
A<\/strong><\/em>Attualmente, nella maggior parte dei casi, questa verifica viene fatta manualmente, o per dirla in modo pi\u00f9 schietto: una settimana prima dell'arrivo dei revisori, si raccoglie ogni tipo di documentazione o - ancora peggio! - le prove sono create dopo il fatto. La linea di fondo \u00e8 che gli ingegneri automobilistici altamente qualificati sono impegnati a riempire pagine e pagine di fogli Excel. Non \u00e8 un valore aggiunto particolare, per non dire altro.<\/p>\n Conformit\u00e0 implementata in modo significativo<\/strong><\/p>\n <\/p>\n Questo approccio inefficiente \u00e8 dovuto, tra l'altro, al fatto che i processi non sono sempre definiti in modo pratico nel quadro dei programmi Automotive SPICE \u00ae o CMMI. In troppi casi, la definizione dei processi \u00e8 fatta da consulenti. Essi \"prescrivono\" determinati processi a un'azienda senza tener conto se questi processi sono allineati con gli obiettivi aziendali o, pi\u00f9 in generale, con le realt\u00e0 di<\/p>\n <\/p>\n Processi senza rilevanza pratica<\/strong><\/em><\/p>\n <\/p>\n dell'azienda. Inoltre, troppi revisori, periti e valutatori controllano ancora i processi in base a liste di controllo per una conformit\u00e0 nominale allo standard. Il risultato sono specifiche di processo completamente irrealistiche, inefficaci o addirittura dannose per il business, che gli sviluppatori e gli ingegneri applicano a malincuore nel migliore dei casi o alla fine ignorano.<\/p>\n <\/p>\n Le pratiche CMMI come \"PP SP 2.6: Plan Stakeholder Involvement\", per esempio, non servono a un fine in s\u00e9! Solo per questo motivo, nessuno dovrebbe creare pagine di documenti, compilare modelli, dare approvazioni e tenere riunioni che durano ore. No, questa pratica vuole semplicemente incoraggiare le persone coinvolte nel progetto a pensarci: Chi pu\u00f2 contribuire al successo del progetto? Come possono queste persone essere coinvolte in modo ottimale nel progetto? Quando dovrebbe accadere? In breve, l'idea di base di modelli come Automotive SPICE \u00ae o CMMI pu\u00f2 essere riassunta con la frase: \"Pensa prima di agire\".<\/p>\n Direttamente nella catena del valore<\/strong><\/p>\n <\/p>\n Ha quindi molto pi\u00f9 senso usare l'esperienza dell'industria aeronautica, della tecnologia ferroviaria e di altre aree di applicazione critiche per la sicurezza e costruire la verifica della conformit\u00e0 direttamente nella catena del valore dello sviluppo (analisi, progettazione, implementazione, integrazione, test). Se certe attivit\u00e0 non hanno valore aggiunto, dovrebbero essere eliminate immediatamente. Tuttavia, la creazione di valore non dovrebbe essere considerata solo in termini di benefici a breve termine del progetto. Piuttosto, i seguenti miglioramenti di valore, per esempio, dovrebbero essere presi in considerazione:<\/p>\n <\/p>\n Per raggiungere questo obiettivo, i concetti di tracciabilit\u00e0 conosciuti dalla gestione dei requisiti, cio\u00e8 la tracciabilit\u00e0 di un requisito attraverso la progettazione, l'implementazione e il test, vengono utilizzati e applicati alla gestione dei processi. La parte superiore della figura 1 mostra questa connessione tra il livello di conformit\u00e0 e il livello di processo.<\/p>\n Accettazione attraverso l'intuizione<\/strong><\/p>\n <\/p>\n In particolare, gli standard sono suddivisi nei loro requisiti individuali, che sono mappati nei rispettivi elementi della descrizione del processo standard. Per esempio, un requisito \"6-6.4.1: I requisiti di sicurezza del software devono affrontare ogni funzione basata sul software il cui fallimento potrebbe portare ad una violazione di un requisito tecnico di sicurezza assegnato al software\" da ISO 26262 \u00e8 mappato alle fasi del processo \"Elaborare i requisiti\", \"Convalidare i requisiti\" e il prodotto di lavoro \"Requisiti software\".<\/p>\n <\/p>\n Il grafico 1 pu\u00f2 essere usato per l'analisi del gap in entrambe le direzioni:<\/p>\n <\/p>\n Eccesso di \"rifiuti di processo<\/strong><\/em><\/p>\n <\/p>\n C'\u00e8 una giustificazione metodologica, tecnica, normativa o commerciale per ogni fase del processo? In questo modo, i passi superflui (\"rifiuti\" nel senso di LEAN o semplicemente eccesso di \"rifiuti di processo\") possono essere identificati ed eliminati.<\/p>\n <\/p>\n L'accettazione nasce attraverso l'intuizione razionale ed emotiva - un'intuizione molto diffusa in psicologia. L'obiettivo \u00e8 quindi quello di mostrare una catena continua di ragionamento dai singoli requisiti standard alle singole fasi di sviluppo. Questo rende trasparente per l'utente finale il motivo per cui certi passi devono essere eseguiti. Questa trasparenza assicura una maggiore comprensione e, in ultima analisi, porta ad una maggiore accettazione del processo. \u00c8 molto pi\u00f9 probabile che tutti capiscano e seguano le specifiche e i regolamenti se le ragioni delle rispettive misure sono spiegate chiaramente e rese comprensibili per loro. Questa procedura pu\u00f2 essere applicata in parallelo a diverse norme o standard. Esempi di tali combinazioni sono<\/p>\n <\/p>\n Lo sforzo pu\u00f2 essere ulteriormente ridotto se queste specifiche sono combinate tra loro e i processi sono mappati nel modello globale risultante. In questo modo, le sovrapposizioni nel contenuto delle specifiche possono anche essere eliminate e implementate uniformemente nei processi. Questo approccio \u00e8 gi\u00e0 stato implementato con successo per i modelli SPICE e CMMI e per gli standard di sviluppo dei dispositivi medici. Il numero di individui<\/p>\n <\/p>\n Rendere i passi trasparenti<\/strong><\/em><\/p>\n <\/p>\n i requisiti standard potrebbero essere ridotti di oltre il 75 per cento.<\/p>\n <\/p>\n Tuttavia, questi processi sono ancora a livello teorico. Troppe aziende rimangono bloccate nella gestione dei processi con la pura pubblicazione dei processi. Una visualizzazione dei processi - per quanto utile - pu\u00f2 essere solo un primo passo. Per miglioramenti reali nello sviluppo quotidiano, \u00e8 cruciale che ogni passo del processo definito abbia davvero senso e sia implementato nella pratica.<\/p>\n Processi concreti attraverso il tailoring<\/strong><\/p>\n <\/p>\n Per l'utente finale, \u00e8 importante che i processi siano il pi\u00f9 possibile concreti e adatti al suo scopo. Tuttavia, \u00e8 nella natura delle cose che i processi standardizzati sono inevitabilmente astratti e quindi, nei casi pi\u00f9 rari, veramente concisi abbastanza da essere direttamente utili e applicabili nella pratica quotidiana del progetto.<\/p>\n <\/p>\n Chiunque abbia gestito o giocato un ruolo decisivo in diversi progetti di sviluppo pu\u00f2 confermare che due progetti di sviluppo non seguono mai esattamente lo stesso processo. C'\u00e8 troppa varianza, per esempio, negli obiettivi del progetto, nelle tecnologie usate, nei requisiti del cliente, nelle strutture organizzative, o nell'esperienza di coloro che sono coinvolti nel progetto. Inoltre, le buone organizzazioni imparano costantemente, si adattano alle circostanze che cambiano e usano le nuove tecnologie con profitto. Nessun processo standard potr\u00e0 mai tenere conto di questa varianza e velocit\u00e0 di cambiamento.<\/p>\n <\/p>\n Tramite l'adattamento ai processi accettati<\/strong><\/em><\/p>\n <\/p>\n Si tratta quindi di adattare la descrizione di un processo standard astratto all'applicazione specifica del progetto, cio\u00e8 selezionare i passi giusti per un progetto particolare e descriverli nel contesto del progetto. Un processo standard specifica, per esempio, che i requisiti devono essere registrati, documentati e controllati per ragionevolezza e completezza. Come questo debba essere fatto in modo ottimale in un progetto concreto dipende molto dal contesto.<\/p>\n <\/p>\n In un ambiente critico per la sicurezza, come un'automobile, questi requisiti devono normalmente essere registrati in modo strutturato, documentati in un sistema di gestione dei requisiti e controllati tramite verifica e validazione. ISO 26262 fa una serie di specifiche chiare qui: Per esempio, tutti i requisiti di sicurezza tecnica devono essere controllati per la conformit\u00e0 e la coerenza con il concetto di sicurezza funzionale e le ipotesi architettoniche preliminari (ISO 26262:2011 4-6.4.6.1). Questa prova pu\u00f2 essere fornita in modo efficiente solo da sistemi di gestione dei requisiti almeno semi-automatici.<\/p>\n <\/p>\n Tuttavia, ci sono anche aree di sistema in ogni automobile che non sono classificate come critiche per la sicurezza, per esempio la maggior parte delle funzioni di un sistema di infotainment. Un esame formale di tutti i requisiti per tali sistemi supererebbe completamente il limite. Questo significa che si pu\u00f2 rinunciare alla gestione strutturata di questi requisiti? Assolutamente no! I requisiti per i sistemi di infotainment sono molto estesi; non \u00e8 raro che sistemi complessi abbiano fino a mille requisiti individuali. \u00c8 impossibile gestire un tale numero di requisiti in modo significativo usando Excel, anche se molte aziende cercano di farlo ancora oggi, a volte su molte varianti di prodotto.<\/p>\n <\/p>\n In altre aree del sistema, pu\u00f2 essere pi\u00f9 efficiente descrivere i requisiti con casi d'uso o in modo meno strutturato con storie utente e procedere direttamente all'implementazione senza ulteriori test.<\/p>\n <\/p>\n Quindi, come si fa ad applicare processi standard astratti a circostanze concrete del progetto? La soluzione \u00e8: attraverso la personalizzazione del processo. Sartoria significa due cose:<\/p>\n <\/p>\n L'adattamento dei processi \u00e8 un altro passo importante verso processi significativi, concreti e accettati nello sviluppo. Tuttavia, per ottenere il maggior valore aggiunto possibile, \u00e8 fondamentale che l'implementazione pratica sia la pi\u00f9 efficiente possibile.<\/p>\n Efficienza attraverso l'automazione<\/strong><\/p>\n <\/p>\n Come passo finale verso un orientamento del processo a valore aggiunto, le fasi del processo pi\u00f9 importanti dovrebbero quindi essere automatizzate. Questo vale, per esempio, per i processi di cambiamento, costruzione o rilascio. Qui, i processi specificati dal tailoring sono usati direttamente negli strumenti PLM\/ALM che gli ingegneri usano ogni giorno per sviluppare hardware, software ed elettronica. Le moderne piattaforme di sviluppo possono essere configurate su una base specifica del progetto per mezzo di definizioni di processo o contenere motori di flusso di lavoro che, per esempio, gestiscono le richieste di cambiamento e le controllano attraverso diverse discipline fino a quando non vengono implementate. La parte inferiore della figura 1 mostra questa connessione tra il livello di processo e il livello di esecuzione.<\/p>\n <\/p>\n Catena di prove sullo sfondo<\/strong><\/em><\/p>\n <\/p>\n Dal punto di vista della conformit\u00e0, si ottiene automaticamente una catena continua di prove dai requisiti delle norme ai risultati concreti del lavoro. Se i moderni strumenti PLM\/ALM sono accoppiati a sistemi di gestione dei processi adeguatamente attrezzati, questa catena di prove funziona completamente senza interruzione dei media o intervento manuale.<\/p>\n <\/p>\n Questo significa che le prove sono raccolte in background attraverso la normale esecuzione dei processi nei progetti di sviluppo e possono essere generate come un rapporto con un riferimento diretto alle norme e agli standard, se necessario. Gli ingegneri sono coinvolti esclusivamente nell'aggiunta di valore, e la verifica viene generata automaticamente. Naturalmente, questo approccio funziona anche in parallelo con diversi standard e norme. I principali produttori di veicoli e i loro fornitori ottengono in questo modo guadagni di efficienza che sono ben nella gamma di percentuali a due cifre.<\/p>","protected":false},"excerpt":{"rendered":" Aktuell erfolgt dieser Nachweis in den meisten F\u00e4llen manuell, oder plakativer ausgedr\u00fcckt: eine Woche, bevor die Pr\u00fcfer anr\u00fccken, sucht man alle Arten von Dokumentation zusammen oder \u2013 noch schlimmer! \u2013 erstellt die Nachweise im Nachhinein. Im Endeffekt sind hochqualifizierte Automotive-Ingenieure damit besch\u00e4ftigt, seitenlange Excel-Sheets auszuf\u00fcllen. Das ist, gelinde gesagt, nicht besonders wertsch\u00f6pfend. […]<\/p>\n","protected":false},"author":66,"featured_media":12701,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[4],"tags":[4804],"class_list":["post-12698","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-risikomanagement","tag-9-2013"],"acf":[],"yoast_head":"\n\n
\n
\n
\n