embedded - tesis - ¿Los desarrolladores integrados son más conservadores que sus hermanos de escritorio?

tesis sobre youtube pdf (10)

He estado en el espacio incrustado por un tiempo, y parece que la mayoría de los programadores con los que hablo parecen estar haciendo las cosas de la misma manera que hace 15 años o más: Desarrollo de Waterfall (ish), herramientas de línea de comando y un pequeño grupo usa pelusa.

Contraste esto con el entorno servidor / escritorio, donde parece haber mucha actividad relacionada con todo tipo de facetas de la programación:

XP, Scrum, Iterativo, Lean / Agile
Integración continua
Compilaciones automatizadas
Marcos de prueba de unidades automatizadas
Soporte de herramienta de refactorización

¿Es solo que el entorno integrado hace que sea más difícil implementar nuevas prácticas o herramientas?
¿Es que la mentalidad de los programadores incrustados los aleja de las nuevas herramientas / conceptos?
¿Es esa gestión en la típica industria incorporada detrás de la curva en comparación con los campos enfocados en TI?

Me doy cuenta de que esto es una generalización, y algunos proyectos integrados utilizan Scrum, Agile, CI, Builds Automatizadas (de hecho, trabajé en una empresa que ya tenía eso desde los años 80). Pero mi impresión es que es un porcentaje muy pequeño.

¿Es solo que el entorno integrado hace que sea más difícil implementar nuevas prácticas o herramientas?

Es en parte una cuestión de escala. El software NO es el producto, el producto es el producto. sin embargo, existen miles de diferentes tipos de microcontroladores y microprocesadores, y los miles más populares tienen 3-4 compiladores diferentes que no son completamente compatibles.

Entonces, una herramienta determinada solo será utilizada por unos pocos cientos o miles de ingenieros.

En el desarrollo de Windows, sin embargo, hay millones de programadores de muchos niveles: las herramientas producen software directamente, que es el producto, y por lo tanto, obtendrá más visitas y más dinero.

Cada nuevo producto que saca un ingeniero puede tener un procesador diferente.

¿Es que la mentalidad de los programadores incrustados los aleja de las nuevas herramientas / conceptos?

Los programadores integrados generalmente son ingenieros de software o firmware, a diferencia de los programadores. La ingeniería implica una cierta cantidad de diseño, análisis de diseño y prueba de diseño antes de la implementación; en otras palabras, se realiza una tonelada de trabajo antes de escribir la primera línea de código, y la documentación, idealmente, es lo suficientemente específica como para que la implementación simplemente pseudocódigo como documentación en código compilable.

Se necesitan nuevas herramientas y conceptos en la fase de diseño, no en la fase de implementación. Un IDE con intellisense puede ser agradable, pero para el momento en que se escribe el código es inútil, ya saben lo que necesitan.

CAD: diseño asistido por computadora: se están desarrollando herramientas para ingenieros de firmware que se utilizan en la fase de diseño para desarrollar modelos y simulaciones que se convierten directamente en código. Matlab y simulink son buenos ejemplos de esto. El sistema como un todo está diseñado.

De hecho, uno podría preguntarse por qué los desarrolladores de software aún escriben código mientras los ingenieros elaboran diagramas de flujo de datos / programas y diagramas de máquinas de estados. ¿Por qué la captación de UML es tan lenta en el mundo de las aplicaciones? Parece que los desarrolladores de aplicaciones pueden usar algunas de las herramientas de uso común entre los ingenieros de sistemas integrados ...

¿Es esa gestión en la típica industria incorporada detrás de la curva en comparación con los campos enfocados en TI?

En realidad, es al revés. Cuando se inicia un proyecto, los ingenieros tienen que elegir el procesador.

Los fabricantes de procesadores obtienen menos dinero en chips más antiguos, por lo que lanzan los últimos y mejores, y en general son más baratos en general que los chips utilizados en el diseño anterior (ya sea por encogimientos, más integración, etc.).

Entonces, el diseño está usando las últimas y mejores fichas.

El inconveniente es que el compilador y las herramientas a menudo son inmaduros. Solo pueden construir tanto en las herramientas más antiguas, y dado que el objetivo se mueve con cada nuevo procesador, no pueden enfocarse en muchas de las características que a los programadores de aplicaciones les pueden gustar. Especialmente porque muchas de esas características no serán útiles para un ingeniero integrado.

Hay muchos otros factores, algunos de los cuales se enumeran en otras respuestas, pero en realidad es un campo diferente, aunque ambos implican programación.

-Adán

Diría diferentes tipos de entornos problemáticos.

El mayor problema con la metodología de cascada es que los requisitos cambian. En cada entorno en el que he estado, ha habido al menos la posibilidad de un cambio de requisitos, lo que significa que las metodologías exitosas son aquellas que mantienen la flexibilidad el mayor tiempo posible. Incluso si el cliente ha firmado con sangre y puede perder su mano izquierda si sugiere un cambio, habrá cambios en el futuro.

En la programación integrada, es posible fijar los requisitos desde el principio. Vienen del comportamiento del sistema como un todo, y los ingenieros son buenos para fijar los requisitos del sistema. Nadie va a llegar a la mitad y decir que el usuario ahora quiere que el marcapasos proporcione impulsos sincopados mientras el receptor está bailando.

Una vez que los requisitos se congelan más allá de la descongelación, lo que nunca sucede en el software diseñado para uso humano, la cascada es una metodología muy eficiente. El equipo procede desde requisitos bien especificados hasta el diseño general, luego el diseño detallado, luego la codificación, verificando todo el proceso de forma correcta. Entonces es hora de depurar el código (ya que nunca es perfecto cuando se escribe), y las pruebas finales para asegurarse de que el código cumpla con los requisitos.

Estas son algunas razones por las que puedo pensar:

Los equipos integrados suelen ser más pequeños que los equipos de escritorio / web. La base del código es más pequeña.
Las pruebas del sistema son mucho más importantes que las pruebas unitarias. El software debe probarse junto con el hardware. Las pruebas automatizadas no son posibles y solo se pueden aplicar a una pequeña fracción de la base de códigos.
Los ingenieros integrados tienen un conjunto de habilidades diferente que los ingenieros de software. Interactúan con el hardware, saben cómo usar un osciloscopio y un analizador lógico. Generalmente, la parte difícil de su trabajo es encontrar un problema técnico en el hardware. No tienen tiempo para adoptar metodologías de software modernas.

Todos estamos acostumbrados al hecho de que nuestra computadora de escritorio se cuelga de vez en cuando (o al menos una aplicación en el escritorio desaparece de repente). No es la gran cosa. El próximo parche lo arreglará.

En el espacio incrustado, estás creando algo que no se puede reparar. Las vidas pueden depender de su dispositivo (en un automóvil, un elevador o un sistema médico). La mayoría de los dispositivos están instalados y luego deben funcionar desatendidos durante años. Así que las personas integradas tienden a ser muy conservadoras. TCP / IP suele ser "demasiado moderno". Se adhieren a su confiable bus serie con una "pila" de comunicación que tiene aproximadamente 50 líneas de código ensamblador.

Lo que es peor, simplemente no tiene la abundancia de espacio en el dispositivo, lo que significa que no puede usar uno de los últimos lenguajes de programación que hacen que TDD y las compilaciones automatizadas sean una bendición.

A continuación, muchos entornos de desarrollo integrados son propietarios. Si su proveedor no lo admite, no lo obtendrá. Linux ha comenzado a debilitar esto en los últimos años, pero muchos dispositivos aún no son lo suficientemente potentes como para ejecutar Linux. E incluso si lo fueran, la potencia de la CPU se usaría para otra cosa en lugar de ejecutar un sofisticado sistema operativo que viene con la fuente.

Entonces, sí, hay poderosas fuerzas trabajando en segundo plano para mantener el espacio incrustado donde está.

Yo diría que es más la falta de buenos conjuntos de herramientas. Es realmente frustrante cuando desea utilizar C ++ para sus características de tiempo de compilación no presentes en C (plantillas, espacios de nombres, orientación a objetos, etc.) en lugar de sus características de tiempo de ejecución (excepciones, funciones virtuales), pero los fabricantes de dispositivos y Los terceros solo le dan un compilador de C, no C ++. Esto probablemente resulte más del tamaño del mercado (cientos de millones de PC con Windows, con cientos de miles o incluso millones de desarrolladores, frente a cientos de miles de Chip X, con cientos o pocos miles de desarrolladores) que desde la capacidad del dispositivo.

editar: robustez w / r / t: hay diferentes mercados por ahí. El mercado de automóviles / ascensores / aeronáutica / dispositivos médicos va a tener que ser riguroso para deshacerse de los errores. Otros mercados (juguetes, reproductores de MP3 y otros productos electrónicos de consumo) pueden ser menos rigurosos, especialmente si es posible actualizar el código en el campo. ("¡Ups! ¡Lamentamos que hayamos eliminado tu biblioteca de música! Solo solucionamos ese error, ¡puedes obtener la última versión en nuestro sitio web a tu conveniencia!")

¿Los desarrolladores integrados son más conservadores que sus hermanos de escritorio?

Sí, porque están más preocupados por las consecuencias de cometer errores. Es un gran problema parchar un dispositivo integrado. No tanto para una aplicación de escritorio.

El desarrollo de Waterfallish es necesario en el mundo integrado porque generalmente estás construyendo hardware al mismo tiempo que el software. Necesita saber lo antes posible cuánta memoria, cuánta velocidad de procesador, qué tamaño de flash, qué si necesita hardware especial, etc. El diseño de hardware no puede completarse hasta que sepa estas respuestas. Una vez que decides, eso es más o menos. El tiempo de espera para volver a hacer una placa es demasiado largo. Si te equivocas, el software tendrá que solucionar cualquier problema. No suele ser una situación ideal.

En cuanto a las herramientas , eso se basa en gran medida en lo que el proveedor proporciona y en los sesgos de los desarrolladores. En algunos proyectos, he utilizado XP Embedded y obtuve casi todo lo que obtiene el desarrollador de escritorio.

XP, Scrum, Iterativo, Lean / Agile:

Como la mayor parte del diseño se realiza por adelantado (por necesidad), y generalmente no tiene hardware en funcionamiento cuando es el momento de programar, los procesos rápidos de entrega en realidad no proporcionan mucho beneficio.

Integración continua / compilaciones automatizadas Es agradable tener, pero no realmente necesario. Qué ... tarda aproximadamente 15 segundos en abrir el IDE y presionar el botón de compilación.

Pruebas unitarias automatizadas

No hay razón por la que esto no se debe hacer, pero solo una parte del código puede probarse de verdad porque la otra parte depende del hardware o tiene otras dependencias como el tiempo. Entonces, realmente no se puede decir si el código funciona con las pruebas automáticas.

Refactoring Tool Support

El proveedor de productos de procesadores integrados es el procesador. Proporcionan el soporte IDE para animarlo a comprar su procesador. No podrían permitirse pagar por un equipo de desarrollo del tamaño de Visual Studio para agregar todas las características al IDE que ni siquiera es su producto.

También agregaría un par de puntos aquí:

En general, los proyectos integrados tienden a ser más pequeños que los proyectos de escritorio. Esto disminuye la necesidad de procesos de software muy elaborados.
Los requisitos para el proyecto integrado suelen ser precisos y mejor definidos. Por lo tanto SCRUM y ágil no son tan cruciales
Finalmente, los proyectos integrados generalmente son una combinación de software y hardware. Como el software es solo una parte del proyecto, los desarrolladores integrados invierten menos tiempo en los procesos de software.

Los programadores integrados son en su mayoría ingenieros eléctricos, no informáticos o ingenieros de software.

Se destacan en su campo de experiencia. Traen un enfoque más lento y metódico que la mayoría de los programadores de computadoras. Cuando se trata de programar el firmware, los ingenieros eléctricos saben lo suficiente como para ser peligrosos.

Estas son algunas de las cosas que he notado que los ingenieros eléctricos están haciendo en C:

Todo el código en UN SOLO archivo
Matemáticas como nombres de variables: x, y, z
No o sangría faltante
Sin encabezados de comentarios stardard
Sin comentarios en absoluto
Demasiados comentarios

En su defensa, EE''s no se entrenó para ser programadores de computadoras, no es su trabajo. Creo que el software es la parte más difícil de crear dispositivos integrados. Diseñar PCB y elegir componentes requiere habilidad, pero es insignificante en comparación con la complejidad de 10.000 líneas de código.

Los programadores integrados también tienen que lidiar con los IDE que se ven y se comportan como los IDE de los 90.

Estoy de acuerdo con mucho de lo que se ha escrito aquí:

Herramientas antiguas sin alarmas (muchas menos refactorizaciones disponibles debido a las directivas de preprocesador de C / C ++, si las hay) (lleva mucho tiempo elegir un marco de prueba unitario frente a simplemente usar JUnit).
Es cierto que la cascada se siente más eficiente. Si voy a abrir el capó y entrar en un lugar de difícil acceso, querré hacer todo lo que pueda mientras esté allí, en lugar de salir y cerrar el cofre después de cada tarea solo para abrir de nuevo. La idea de que la creación de las características más importantes primero le permite la opción de envío cuando se le prometió en lugar de llegar tarde también puede ser difícil de entender cuando cree que nada es opcional, lo que podría ser cierto. IME, sin embargo, cuando la fecha límite se cierne sobre algo siempre se vuelve innecesario.
Una menor visibilidad del sistema hace que sea más arriesgado volver a visitar el código existente para refactorizar o cambiar la funcionalidad. A menudo hay problemas de tiempo, que las pruebas automatizadas que se ejecutan en el host utilizando stubs y burlas no se verán. Puede ser difícil para alguien que ha sido mordido por estos problemas tomar una perspectiva diferente.
Añadiré uno más; el lenguaje de agile / scrum está en los términos del programador de estación de trabajo. Para un desarrollador integrado que sabe lo suficiente C para realizar el trabajo, ¿qué clase, objeto o método tiene? Cuando el "usuario" se considera típicamente como una persona física que hace clic y escribe, y el producto no tiene una interfaz de usuario, es fácil descartar la idea como No aplicable. Esto puede cambiar con el próximo libro de James Grenning sobre TDD en C. He estado leyendo el ebook beta y es bastante bueno.

También postularía que algunos campos son intrínsecamente conservadores. La industria del transporte, por ejemplo, donde los trenes y aviones pueden tener una duración de vida de 30 años más o menos. Los clientes tienden a exigir prácticas comprobadas y verdaderas, probablemente derivadas de IEEE. Cascada es lo que los clientes saben, la cascada es lo que demandan los clientes.