Indice del forum Il forum sulla Qualità di QualitiAmo
Torna all'homepage di QualitiAmo
 
 FAQFAQ   CercaCerca   Lista utentiLista utenti   GruppiGruppi   RegistratiRegistrati 
 ProfiloProfilo   Messaggi privatiMessaggi privati   Log inLog in 

Sviluppo SW e airworthiness (AMC-20 e altre amenita' EASA)
Vai a 1, 2  Successivo
 
Nuovo argomento   Rispondi    Indice del forum -> La Qualità applicata
Precedente :: Successivo  
Autore Messaggio
Slender Man
M.A.S.P.


Registrato: 20/04/12 14:28
Messaggi: 3220

MessaggioInviato: Mer Giu 15, 2022 9:03 am    Oggetto: Sviluppo SW e airworthiness (AMC-20 e altre amenita' EASA) Rispondi citando

Buongiorno a tutti.

Mi trovo a dover capire quali sia il perimetro di accettabilità per un processo di sviluppo e validazione SW in contesto aeronautico (non per avionics, ma per controllo sistemi stivati).

Esiste una "best practice", chessò basata su Agile, che viene utilizzata da tutti, o ognuno si disegna il suo personale percorso di sviluppo secondo le sue esigenze? Se è il secondo caso, qual è la linea guida per capire se un processo è "accettabile" o meno? Quali sono i requisiti?

Ho un sacco di pensieri, probabilmente per analogia con A-Spice, che mastico poco, ma poche certezze.

Grazie a chi riduce la mia confusione e limita la mia ignoranza.
_________________
"It's my way, or the highway." (James Dalton, Esq.)
"Manly hearts to guard the fair" (Job Description)
Top
Profilo Invia messaggio privato
KK
King of Kuality


Registrato: 23/04/09 14:36
Messaggi: 10262

MessaggioInviato: Gio Giu 16, 2022 12:04 pm    Oggetto: Rispondi citando

Purtroppo, pur occupandomi talvolta di aeronautica, non sono per nulla ferrato sul discorso software e validazioni, quindi seguo con interesse la discussione per vedere eventuali feedback e soluzioni
_________________
Konsulente Kualità
Top
Profilo Invia messaggio privato
Slender Man
M.A.S.P.


Registrato: 20/04/12 14:28
Messaggi: 3220

MessaggioInviato: Gio Giu 16, 2022 12:18 pm    Oggetto: Rispondi citando

Per me è tipo l'armadio di Narnia. Era una cosa che sapevo esistesse, pensavo di sapere cosa contenesse, ma quando lo apri capisci che dentro c'è un mondo intero.

Dove nevica.
_________________
"It's my way, or the highway." (James Dalton, Esq.)
"Manly hearts to guard the fair" (Job Description)
Top
Profilo Invia messaggio privato
KK
King of Kuality


Registrato: 23/04/09 14:36
Messaggi: 10262

MessaggioInviato: Gio Giu 16, 2022 1:42 pm    Oggetto: Rispondi citando

Solo per un tentativo di ragionamento, secondo te il processo di accettabilità di un software può essere riconducibile ai requisiti di validazione di un progetto in generale (i vari punti 8.3) definendo in maniera puntuale le personalizzazioni del caso in ambito software?

Sei sicuro che ci debba essere una linea guida specifica?
Se sì, potrebbe assomigliare (per concetto di applicabilità) alla 19011 per quanto attiene agli audit interni?

Pensi che la ISO 27001 sulla sicurezza dei dati informatici possa aiutare?
_________________
Konsulente Kualità
Top
Profilo Invia messaggio privato
Slender Man
M.A.S.P.


Registrato: 20/04/12 14:28
Messaggi: 3220

MessaggioInviato: Ven Giu 17, 2022 9:15 am    Oggetto: Rispondi citando

Ciao KK, grazie delle domande.

In linea generale sì: definisco un set di
- cose che devo tenere presente quando sto sviluppando (es. regole per la struttura del codice e dei commenti, in modo che per esempio il codice sia mangiabile da Doxygen o altri tool simili, regole per il "modo" in cui il team di sviluppo lavora, es. gestione dei backlog, sprint-like approach o simile)
- cose che devo fare per stabilire che una certa release del SW "va bene", compresi anche i vari test incrociati (sanity, regressione...)
- cose che devo documentare per fare in modo che le varie fasi dello sviluppo siano comprensibili, come archivio queste cose in repository, come gestisco accessi e versioni...
- fasi di controllo/review del progetto (quelle del prodotto le considero come parte del testing): che verifiche devo fare, chi le fa, che faccio coi risultati...

Insomma, prendo i classici obiettivi del lavoro di un dev (Maintainability/Flexibility/Portability/Efficiency/Reusability/Testability/Modularity/Readability) e spiego bene come faccio a raggiungerli, uno per uno, con una specifica "linea guida"

La 27001 fa da sfondo, se vuoi, mi sembra che più che altro il campo da gioco sia la 33001... Secondo me tutti i miei dubbi nascono dal fatto che non conosco la 33001 bene quanto vorrei.
_________________
"It's my way, or the highway." (James Dalton, Esq.)
"Manly hearts to guard the fair" (Job Description)
Top
Profilo Invia messaggio privato
jeancloude17
Apprendista forumista


Registrato: 29/12/21 12:55
Messaggi: 112
Residenza: San Giuliano terme (pi)

MessaggioInviato: Mer Ott 05, 2022 10:07 am    Oggetto: Rispondi citando

Ciao Slander, Ciao KK
Slender Man ha scritto:

La 27001 fa da sfondo, se vuoi, mi sembra che più che altro il campo da gioco sia la 33001... Secondo me tutti i miei dubbi nascono dal fatto che non conosco la 33001 bene quanto vorrei.


Provo a seguire questa metodologia per campionare un processo di programmazione, studio un po' il tuo commento e le varie ISO che hai menzionato

Ciao a tutti e grazie per l'attenzione
Top
Profilo Invia messaggio privato
Slender Man
M.A.S.P.


Registrato: 20/04/12 14:28
Messaggi: 3220

MessaggioInviato: Gio Ott 06, 2022 1:38 pm    Oggetto: Rispondi citando

Temo di non aver capito.
_________________
"It's my way, or the highway." (James Dalton, Esq.)
"Manly hearts to guard the fair" (Job Description)
Top
Profilo Invia messaggio privato
jeancloude17
Apprendista forumista


Registrato: 29/12/21 12:55
Messaggi: 112
Residenza: San Giuliano terme (pi)

MessaggioInviato: Gio Ott 06, 2022 2:49 pm    Oggetto: Rispondi citando

Mi rifaccio al tuo ultimo commento

Quello che interessa a me, sentitevi liberi di correggere, (non sono ancora del mestiere) è descrivere un processo di modellazione per farne un modulo da poter inserire nei processi operativi della mia azienda.
Il mio obiettivo è: portare la certificazione ISO 2008 alla versione ISO 2015.

Ho fatto questa modifica al manuale, (perdonate la sincerità, ma ho fatto esattamente questo, durante la mia permanenza in azienda non mi sono mai alzato dalla scrivania), ho preso i documenti vecchi ew li ho organizzati in modo da renderli compatibili con la nuova versione. Inerente alla qualità posso aver creato e disatribuito i moduli per valutare la soddisfazione del personale e dei clienti, essendo un azienda pic cola audit veri e propri non li ho mai fatti, (molto pochi almeno e non sono durati più di 12 minuti)
Comunque questo ho fatto.
L'auditor di terze parti mi ha detto che mancano kpi dai cui traspare la salute aziendale, e che diano indicazione di dove poter intervenire in caso qualcosa non andasse. ( Questo è quello che ho capito della funzionalità dei KPI)

Noi in azienda ci occupiamo anche di modellazione software
(se da questo post riewsco a capire che tipo di informazioni mi mancano, non esiterò a chiederle), quindi ho pensato di costruire un modulo che partendo dalla richiesta del cliente finisca con la consegna che ottiene il cliente.

Nei nostri processi operativi tale operazione viene descritta in maniera molto lasca, i nostri PR potrebbero ricoprire qualunque azienda che produce qualunque prodotto/servizio.

Quindi provavo a capire come posso compilare tale modulo, e mi sono imbattuto nel tuo poste che dice:

Slender Man ha scritto:

In linea generale sì: definisco un set di

- cose che devo tenere presente quando sto sviluppando (es. regole per la struttura del codice e dei commenti, in modo che per esempio il codice sia mangiabile da Doxygen o altri tool simili, regole per il "modo" in cui il team di sviluppo lavora, es. gestione dei backlog, sprint-like approach o simile)

- cose che devo fare per stabilire che una certa release del SW "va bene", compresi anche i vari test incrociati (sanity, regressione...)

- cose che devo documentare per fare in modo che le varie fasi dello sviluppo siano comprensibili, come archivio queste cose in repository, come gestisco accessi e versioni...

- fasi di controllo/review del progetto (quelle del prodotto le considero come parte del testing): che verifiche devo fare, chi le fa, che faccio coi risultati...


Prendi questa parte, che dirama la metrica del modulo, o perlomeno io ci vedo un modulo con il quale descrivere lo sviuluppo della modellazione software... Usiamo mathlab e simulink, ma potrei chiedere perché è da un po' che non ci guardo; Comunque, se parlo con un programmatore e gli elenco i punti da te dichiarati, sono in grado di descrivere il processo di modellazione software?

pensa1



Slender Man ha scritto:


Insomma, prendo i classici obiettivi del lavoro di un dev (Maintainability/Flexibility/Portability/Efficiency/Reusability/Testability/Modularity/Readability) e spiego bene come faccio a raggiungerli, uno per uno, con una specifica "linea guida"


Ecco, fai conto gli espongo questa statement, sono in grado di costruire il processo operativo relativo alla modellazione?

Slender Man ha scritto:


La 27001 fa da sfondo, se vuoi, mi sembra che più che altro il campo da gioco sia la 33001... Secondo me tutti i miei dubbi nascono dal fatto che non conosco la 33001 bene quanto vorrei.


Queste iso le ho cercate, ma ho trovato solo commenti alle norme e slide (forse) piuttosto che le ISO vere e proprie...


Insomma quello che vi volevo chiedere è:

Come si costruisce un modulo che descrive laq modellazione software mirata all'automotive a trazione elettrica?


Grazie a tutti
Top
Profilo Invia messaggio privato
Slender Man
M.A.S.P.


Registrato: 20/04/12 14:28
Messaggi: 3220

MessaggioInviato: Gio Ott 06, 2022 4:00 pm    Oggetto: Rispondi citando

Ma perché, se non è un requisito, vuoi farti del male da solo?

Comunque in linea di massima la risposta alle tue domande dovrebbe essere sì - dovrebbe essere sufficiente rispondere alle domande che ho fatto io per arrivare alla descrizione di un processo validabile.

Il punto è che non è una passeggiata.

Da quello che racconti sei alle prese con i fondamentali. Non riesco a capire come possa esserci in azienda la competenza per implementare processi come questo. Magari sbaglio.
_________________
"It's my way, or the highway." (James Dalton, Esq.)
"Manly hearts to guard the fair" (Job Description)
Top
Profilo Invia messaggio privato
MikiMarru
Come da manuale


Registrato: 21/11/07 22:34
Messaggi: 1313
Residenza: Brescia

MessaggioInviato: Gio Ott 06, 2022 7:20 pm    Oggetto: Rispondi citando

Slender Man ha scritto:
Ma perché, se non è un requisito, vuoi farti del male da solo?
......
Da quello che racconti sei alle prese con i fondamentali. Non riesco a capire come possa esserci in azienda la competenza per implementare processi come questo. Magari sbaglio.


Concordo su tutto.
Inoltre se il processo era gestito in conformità alla 9001:2008 come indichi, per essere conforme alla 9001:2015 puoi iniziare già solo ad esplicitare una analisi dei rischi di commessa.
_________________
Credo fermamente nel detto: "Non ti do il pesce, ma la canna da pesca, e ti insegno a usarla, perché tu possa pescare da solo". E' possibile che la mia risposta sia da intendere in tal senso.
Top
Profilo Invia messaggio privato
MikiMarru
Come da manuale


Registrato: 21/11/07 22:34
Messaggi: 1313
Residenza: Brescia

MessaggioInviato: Gio Ott 06, 2022 7:31 pm    Oggetto: Rispondi citando

jeancloude17 ha scritto:

L'auditor di terze parti mi ha detto che mancano kpi dai cui traspare la salute aziendale, e che diano indicazione di dove poter intervenire in caso qualcosa non andasse. ( Questo è quello che ho capito della funzionalità dei KPI)
[/b]


Avete fatto lo stage 1 dal quale sono emerse delle NC al sistema da gestire per poter passare lo stage 2.
Sistema quelle, porti a casa la certificazione e raggiungi il primo obiettivo; poi ci saranno successivi audit, dal qualche potranno emergere altre Nc che affronterete mano a mano e progressivamente il sistema migliorerà.


jeancloude17 ha scritto:

Come si costruisce un modulo che descrive laq modellazione software mirata all'automotive a trazione elettrica?
[/b]


Conosco relativamente la progettazione SW, quel poco che ne so mi porta a dubitare che possa essere fatto con UN modulo. Sempre che tu intenda un modulo per il controllo di progettazione / sviluppo.

A meno che tu invece non ti riferisca una rappresentazione del flusso delle attività, in quel caso ti fai descrivere la sequenza delle fasi dal responsabile, metti su carta una bozza, la rivedete insieme, correggi ecc.

Ad ogni modo, ribadisco che se la "documentazione esistente" era conforme alla 9001:2008 è praticamente conforme anche alla 2015.
_________________
Credo fermamente nel detto: "Non ti do il pesce, ma la canna da pesca, e ti insegno a usarla, perché tu possa pescare da solo". E' possibile che la mia risposta sia da intendere in tal senso.
Top
Profilo Invia messaggio privato
jeancloude17
Apprendista forumista


Registrato: 29/12/21 12:55
Messaggi: 112
Residenza: San Giuliano terme (pi)

MessaggioInviato: Ven Ott 07, 2022 9:16 am    Oggetto: Rispondi citando

MikiMarru ha scritto:

Concordo su tutto.
Inoltre se il processo era gestito in conformità alla 9001:2008 come indichi, per essere conforme alla 9001:2015 puoi iniziare già solo ad esplicitare una analisi dei rischi di commessa.



Benissimo... Ci pensavo, in queste ore, alla fine se nella 2008 l'hanno accettato, il processo operativo che hanno descritto come servizio, non ha ricevuto non conformità da parte dell'auditor di 3p, dopo i vostri consigli scelgo nel limite del possibile di non continuare a sabotarmi la vita.


Quello che ti chiedo è....

MikiMarru ha scritto:
puoi iniziare già solo ad esplicitare una analisi dei rischi di commessa.


E qui casco dal pero...
Fai conto che le commesse, sono tutte gestite dal titolare dell'azienda, che le passa agli ingegneri, li segue nei punti chiave, viene contattato in caso di scelte del programmatore compromettenti, fino a che la modellazione è completa e il software viene consegnato

Più o meno dovrebbe andare così, almeno per quanto ne so io, se qualcosa manca per piacere ditemi cosa me la procuro.


Comunque, si parlava di analisi di rischi della commessa

Uno dei rischi nel quale ci possiamo incappare sono i ritardi di consegna?
Sono gli errori nella compilazione del software?
Perché non me ne viene in mente altri...

Grazie a tutti dell'attenzione
Top
Profilo Invia messaggio privato
MikiMarru
Come da manuale


Registrato: 21/11/07 22:34
Messaggi: 1313
Residenza: Brescia

MessaggioInviato: Ven Ott 07, 2022 10:02 am    Oggetto: Rispondi citando

Sei un esperto di Progettazione e Sviluppo Software?
Direi di no

Sei il Responsabile Commerciale o Resp. Tecnico / Progettazione e Sviluppo Software o comel'avetechiamato nell'azienda in cui lavori?
idem

Sono loro a poterlo sapere.

Tralasciando il fatto che sono un pò stupito che non abbiate già affrontato l'argomento nell'aggiornamento del SGQ prima dello Stage 1 - ma lasciamo perdere per il momento - .
In ogni caso, vista la situazione, io mi sentirei di suggerirti di procedere in qs modo:
Nel SGQ da qualche parte metti "nero su bianco" che:
"

    A)in sede di riesame del contratto,
    B) in sede di Riesame degli elementi in ingresso della progettazione
    C) durante la realizzazione

il Resp. A/B/C esegue una analisi dei rischi di commessa, gestendo gli aspetti emersi con le modalità di volta in volta più opportune".
Cosa ottieni:
Che non ti porti a casa una NCMaggiore sul SGQ, perchè il requisito in qs modo è stato considerato (malamente, ma c'è).

Che poi quindi, spero, porterete a casa una NC minore / Osservazione in cui l'Auditor vi chiede di approfondire questo aspetto, delineando meglio le modalità e come sono gestiti i risultati dell'analisi.

In questo modo la questione sarà sul tavolo ed il tuo compito sarà sollecitare e collaborare con "chi in azienda ne sa" affinché l'argomento sia affrontato (altrimenti poi la NC minore diventa Maggiore) con le tempistiche richieste dalla tipologia di rilievo (NMm/OSS) stabilite dall'Ente di certificazione.
_________________
Credo fermamente nel detto: "Non ti do il pesce, ma la canna da pesca, e ti insegno a usarla, perché tu possa pescare da solo". E' possibile che la mia risposta sia da intendere in tal senso.
Top
Profilo Invia messaggio privato
jeancloude17
Apprendista forumista


Registrato: 29/12/21 12:55
Messaggi: 112
Residenza: San Giuliano terme (pi)

MessaggioInviato: Ven Ott 07, 2022 10:48 am    Oggetto: Rispondi citando

Risposte a caldo senza averle lette precedentemente

MikiMarru ha scritto:
Sei un esperto di Progettazione e Sviluppo Software?
Direi di no


Absolutely not


MikiMarru ha scritto:

Sei il Responsabile Commerciale o Resp. Tecnico / Progettazione e Sviluppo Software o comel'avetechiamato nell'azienda in cui lavori?
idem


Absolutely not
Idem


MikiMarru ha scritto:

Sono loro a poterlo sapere.

Tralasciando il fatto che sono un pò stupito che non abbiate già affrontato l'argomento nell'aggiornamento del SGQ prima dello Stage 1 - ma lasciamo perdere per il momento - .


Nello stage 1, il CEO della mia compagnia, non quella nella quale lavoro, siamo un gruppo di 3 società, la certificazione che prenderemo è di gruppo, la società capo-gruppo non è quella dove prendo servizio, ma un altra. (il gruppo è formato da 3 compagnie).
Comunque il primo stage è andato così: 30 minuti il CEO ha descritto l'azienda con le slide, ( come dite voi, scusate se mi permetto, "fuffa")
poi è andato via e sono stato io con l'auditor 3p che mi chiedeva le cose e io rispondevo. Ha segnalato alcune nc dicendo che nel 2 stage dovrebbero essere risolte. E' stato il mio primo audit di 3p a cui ho assistito, non ho i parametri per dire se è andato bene o male


MikiMarru ha scritto:


In ogni caso, vista la situazione, io mi sentirei di suggerirti di procedere in qs modo:
Nel SGQ da qualche parte metti "nero su bianco" che:
"

    A)in sede di riesame del contratto,
    B) in sede di Riesame degli elementi in ingresso della progettazione
    C) durante la realizzazione




Allora, abbiamo moduli dell'offerta, delle vendite, e che io sappia basta. Quindi nelle vendite, c'è nero su bianco il servizio che gli viene offerto, con le tempistiche, il personale coinvolto, il programma per l'implementazione, il costo in denaro insomma tutto quello che bisogna stabilire in modo c he si possa riuscire a elaborare la domanda e farla diventare una consegna.


MikiMarru ha scritto:

il Resp. A/B/C esegue una analisi dei rischi di commessa, gestendo gli aspetti emersi con le modalità di volta in volta più opportune".


Questo viene decisamente fatto, ma con modalità a me ignote, visto che nessuno mi ha mai detto che si procede seguendo questo "iter" da te descritto o un qualsiasi altro metodo.

MikiMarru ha scritto:

Cosa ottieni:
Che non ti porti a casa una NCMaggiore sul SGQ, perchè il requisito in qs modo è stato considerato (malamente, ma c'è).


Non so come vengono trattate le nc, tieni presente che a me non mi dice niente nessuno, quello che mi ha chiesto l'auditor di 3p l'ho estrapolato dal manuale vecchio, non c'è una "politica della qualità", intesa come un auditor che segue i prodotti, dalla domanda alla post consegna, che raccoglie i dati dei clienti e di coloro che vengono serviti, qui-per quanto riguarda la mia organizzazione che è parte del gruppo che verrà certificato, non ho assolutamente accesso a questi dati, non so nemmeno se esistono, (senz'altro esistono), ma sono tagliato fuori, (scusate se vesto i panni della vittima, ma credo che sia così). So solo che stiamo assumendo personale, che le richieste di commessa aumentano, che il fatturato aumenta, ma sul la gestione del software non ne so niente


MikiMarru ha scritto:


Che poi quindi, spero, porterete a casa una NC minore / Osservazione in cui l'Auditor vi chiede di approfondire questo aspetto, delineando meglio le modalità e come sono gestiti i risultati dell'analisi.


L'auditor mi ha chiesto di fare un modulo racp, raccolta azioni correttive e preventive, dove ho segnalato, partendo dalla tows, una serie di azioni per poter correggere o addirittura arginare eventuali futuri problemi. In nessuna di queste viene toccato il lato software
MikiMarru ha scritto:

In questo modo la questione sarà sul tavolo ed il tuo compito sarà sollecitare e collaborare con "chi in azienda ne sa" affinché l'argomento sia affrontato (altrimenti poi la NC minore diventa Maggiore) con le tempistiche richieste dalla tipologia di rilievo (NMm/OSS) stabilite dall'Ente di certificazione.



Provo a fare un audit con un mio collega e provo a capire come scovare e come risolvere una nc


Grazie a tutti


Buon lavoro
Top
Profilo Invia messaggio privato
MikiMarru
Come da manuale


Registrato: 21/11/07 22:34
Messaggi: 1313
Residenza: Brescia

MessaggioInviato: Ven Ott 07, 2022 10:56 am    Oggetto: Rispondi citando

Jean,
se proseguiamo questo discorso qui usciamo ulteriormente dal tema aperto da Slender con il rischio di creare confusione.

Facciamo così, sospendiamo la questione qui e, se ritieni, proseguiamo in un topic diverso
_________________
Credo fermamente nel detto: "Non ti do il pesce, ma la canna da pesca, e ti insegno a usarla, perché tu possa pescare da solo". E' possibile che la mia risposta sia da intendere in tal senso.
Top
Profilo Invia messaggio privato
Mostra prima i messaggi di:   
Nuovo argomento   Rispondi    Indice del forum -> La Qualità applicata Tutti i fusi orari sono GMT + 2 ore
Vai a 1, 2  Successivo
Pagina 1 di 2

 
Vai a:  
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi


Powered by phpBB © 2001, 2005 phpBB Group
phpbb.it