Qual è l'equivalente del software di un ordine di modifica tecnica?

Abbiamo un dispositivo sul quale stiamo valutando di effettuare un aggiornamento software su un microcontrollore bare metal. La nuova immagine verrebbe programmata su tutti i prodotti futuri.

Se dovessi cambiare un componente sul dispositivo, dovrei compilare un ordine di modifica tecnica.

Esiste una procedura industriale equivalente quando si cambia software?

Lo definirei ancora un ECO.

Se il firmware è programmato nel micro in fabbrica, quel firmware e la sua versione specifica dovrebbero essere un elemento pubblicitario nella DBA.
Cambiare il firmware significa cambiare la DBA.
La modifica della distinta base richiede un ECO.

In seguito a ciò, un aggiornamento sul campo del firmware dovrebbe seguire un processo simile a quello che verrebbe seguito se una modifica all'hardware fosse richiesta a un'unità sul campo.
Quindi se lo chiami ECO, anche questo è ECO.

Normalmente una modifica del software è chiamata Patch o (Aggiornamento software). E per quanto ne so (a seconda dell'azienda) le procedure sono denominate Procedura di aggiornamento patch o software.

Tuttavia, nella maggior parte dei casi gli aggiornamenti software non sono altro che l'esecuzione di un'applicazione speciale che si occupa dell'installazione e tutte le conversioni necessarie ecc. Fanno parte della patch.

Quindi, diversamente dallo scambio elettronico di parti, nessun software esistente deve normalmente essere disinstallato o modificato, poiché fa parte del software patch stesso.

Inoltre, nel caso in cui ci siano restrizioni o condizioni su quando l'aggiornamento della patch / software può o non può essere installato, verrà controllato nella patch stessa e verrà installato solo quando è valido per l'installazione (o almeno, dovrebbe funzionare in questo modo ).

Quindi in linea di principio l'aggiornamento patch / software fa molte cose, come (forse non completo):

• Controllare se è possibile installare l'aggiornamento patch / software (ad es. Versioni del sistema operativo, versione corrente installata ecc.)
• In caso contrario, verrà visualizzato un messaggio e la patch / aggiornamento si interromperà.
• Se può essere installato, verranno eseguiti i file che devono essere convertiti (questo a volte fa parte dell'applicazione principale da patchare / aggiornare).
• I nuovi file vengono aggiornati o aggiunti all'applicazione da aggiornare / patchare.
• Vengono visualizzate le note di rilascio (facoltativo).
• L'applicazione viene avviata (facoltativamente).

I termini che utilizzo normalmente sono Richiesta di modifica per cose che devono essere cambiate a causa di requisiti modificati e Rapporto sui problemi per cose che devono essere cambiate a causa di errori.

Questi vengono raccolti e quindi pianificati per cicli di aggiornamento specifici. Se un ciclo è solo interno, si chiama Milestone , se viene distribuito ai clienti, si chiama Release .

Una cronologia tipica presenta alcune pietre miliari prima del rilascio, denominata Release Candidate, che viene sottoposta a test approfonditi e gli eventuali errori rilevati generano ulteriori Rapporti sui problemi che sono di nuovo programmati per il prossimo traguardo se sono abbastanza importanti o per un rilascio successivo in caso contrario.

È anche possibile creare una filiale che affronti specifiche PR solo in risposta ai reclami dei clienti, con una versione separata che non presenta ulteriori modifiche, nella speranza che qui vengano introdotti meno errori. Questo di solito viene fatto solo se lo sforzo per gli aggiornamenti è abbastanza basso (ad es. Perché gli aggiornamenti possono essere installati semplicemente collegando una chiavetta USB con un file con un certo nome su di esso).

Risposta breve: è integrato nel sistema di controllo delle versioni del software.

Risposta lunga:

Il software tende a cambiare molto più rapidamente dell'hardware. Di solito il software utilizza una sorta di sistema di controllo della versione (VCS), come il popolare Git. La maggior parte delle società di software con cui ho lavorato utilizzano un VCS per tenere traccia delle modifiche al software, con ogni commit che spiega il ragionamento alla base della modifica. Alcuni usano anche un tracker di problemi, che tiene traccia di bug noti, miglioramenti e così via. Di solito esiste un processo in cui lo sviluppo avviene su un ramo, quindi lo sviluppo viene testato prima di essere unito in un ramo "principale" (rilascio). Questo tende ad essere molto più efficiente per l'alta frequenza di cambiamenti nello sviluppo del software rispetto al tempo più lento dell'hardware. L'implementazione e il processo specifici variano da una società all'altra ed è spesso influenzato da uno standard ai fini del controllo qualità (ISO9001, AS9100D, ecc.).

Un esempio:

1. Decidi di apportare una modifica.

2. Si crea un problema nel tracker dei problemi.

3. Si crea una filiale per risolvere il problema.
4. Apportare alcune modifiche al software.
5. Le tue modifiche vengono sottoposte a peer review per politica aziendale
6. Emetti una richiesta pull e ti ricolleghi nel ramo dev.
7. Chiudi il problema.

In un'impostazione industriale correttamente gestita, il firmware da sottoporre a flash nel micro è di per sé una parte e ha un numero di parte per quel file eseguibile specifico (file hex o altro). Se si desidera modificare il firmware, si tratta di una modifica alla distinta materiali (distinta materiali). E questo ha bisogno di un ECO come se volessi sostituire un chip.

È davvero così semplice.

C'è un corollario in questo. Se il firmware non ha un numero di parte e non è elencato nella DBA e quindi non è controllato, è probabile che il processo di qualità debba essere migliorato. Se dovresti soddisfare ISO-9001 o qualcosa di simile, questo è un divario definito nel tuo processo che deve essere riparato.

Gli aggiornamenti software sono chiamati patch o sono quelli che sono "aggiornamenti software". Chiedo sempre agli ingegneri del software se l'unità viene aggiornata "all'ultima versione".

Idealmente il controllo delle versioni viene "firmato" dagli stakeholder e testato prima che venga rilasciato in produzione, ma il più delle volte nella maggior parte dei casi questa pratica si verifica solo nella maggior parte dei casi.