Tenemos un dispositivo en el que estamos considerando hacer una actualización de software en un microcontrolador de metal. La nueva imagen se programaría en todos los productos futuros.
Si tuviera que cambiar un componente en el dispositivo, tendría que completar una orden de cambio de ingeniería.
¿Existe un procedimiento industrial equivalente al cambiar el software?
Todavía lo llamaría un ECO.
Si el firmware está programado en el micro en la fábrica, entonces ese firmware y su versión específica debería ser un elemento de línea en la lista de materiales.
Cambiar el firmware significa cambiar la lista de materiales.
Cambiar la lista de materiales requiere un ECO.
Después de eso, una actualización de campo del firmware debe seguir un proceso similar al que se seguiría si se requiriera una modificación del hardware a una unidad en el campo.
Entonces, si llamas a eso un ECO, entonces este también es un ECO.
Normalmente, un cambio de software se denomina parche o (Actualización de software). Y por lo que sé (según la compañía) los procedimientos se denominan Procedimiento de actualización de software o parche.
Sin embargo, en la mayoría de los casos, las actualizaciones de software no son más que ejecutar una aplicación especial que se encarga de la instalación y todas las conversiones necesarias, etc. forman parte del parche.
Por lo tanto, a diferencia del intercambio electrónico de piezas, normalmente no es necesario desinstalar o cambiar ningún software actual existente, ya que es parte del software del parche.
Además, en caso de que haya restricciones o condiciones sobre cuándo se puede o no instalar el parche / actualización de software, se verificará en el parche en sí y solo se instalará cuando sea válida para la instalación (o al menos, debería trabajar de esa manera).
Entonces, en principio, la actualización del parche / software hace muchas cosas, como (posiblemente no esté completa):
Los términos que uso normalmente son Solicitud de cambio para las cosas que deben cambiarse debido a los requisitos modificados, y Informe de problemas para las cosas que deben cambiarse debido a errores .
Estos se recopilan y luego se programan para ciclos de actualización específicos. Si un ciclo es solo interno, se denomina Milestone , si se implementa para los clientes, se denomina Release .
Una línea de tiempo típica tiene algunos hitos antes del lanzamiento, llamado Release Candidate , que se somete a pruebas exhaustivas, y cualquier error que se encuentre allí genera más informes de problemas que nuevamente están programados para el siguiente hito, si son lo suficientemente importante, o una versión posterior si no.
También es posible crear un Sucursal que solo aborde los RP específicos en respuesta a las quejas de los clientes, con una versión por separado que no presente más cambios, con la esperanza de que se introduzcan menos errores aquí. Por lo general, esto solo se hace si el esfuerzo por las actualizaciones es lo suficientemente bajo (por ejemplo, porque las actualizaciones se pueden instalar simplemente conectando una memoria USB con un archivo con un nombre determinado).
Respuesta corta: está integrada en el sistema de control de versiones de software.
Respuesta larga:
El software tiende a cambiar mucho más rápidamente que el hardware. Por lo general, el software utiliza algún tipo de sistema de control de versiones (VCS), como el popular Git. La mayoría de las compañías de software con las que he trabajado usan un VCS para rastrear los cambios en el software, y cada compromiso explica el razonamiento detrás del cambio. Algunos también usan un rastreador de problemas, que rastrea errores conocidos, mejoras y demás. Por lo general, hay un proceso en el lugar donde el desarrollo ocurre en una rama, luego ese desarrollo se prueba antes de fusionarse en una rama "principal" (versión). Esto tiende a ser mucho más eficiente para la alta frecuencia de cambios en el desarrollo de software en comparación con el ritmo más lento en el hardware. La implementación y el proceso específicos de esto varían de una compañía a otra y, a menudo, están influenciados por un estándar para propósitos de control de calidad (ISO9001, AS9100D, etc.).
Un ejemplo:
Decide realizar un cambio.
Crea un problema en el rastreador de problemas.
En una configuración de la industria correctamente ejecutada, el firmware que se incluirá en el micro es una parte y tiene un número de parte para ese ejecutable específico (archivo hexadecimal o cualquier otro). Si desea cambiar el firmware, es un cambio en la lista de materiales (lista de materiales). Y eso necesita un ECO de la misma manera que si quisiera reemplazar un chip.
Es realmente tan simple como eso.
Hay un corolario de esto. Si su firmware no tiene un número de pieza y no aparece en la lista de materiales y, por lo tanto, no está controlado no , entonces es probable que su proceso de calidad necesite una mejora. . Si se supone que debe cumplir con la norma ISO-9001 o algo similar, esta es una brecha definitiva en su proceso que debe solucionarse.
Las actualizaciones de software se denominan parches o son lo que son "actualizaciones de software". Siempre pregunto a los ingenieros de software si la unidad está actualizada "a la última versión".
Lo ideal es que las partes interesadas "firmen" las versiones y las prueben antes de que se publique en producción, pero la mayoría de las veces, la mayoría de las veces, esta práctica solo se realiza en la mayoría de los casos.
Lea otras preguntas en las etiquetas software