¿Cómo estructuran grandes proyectos integrados? [cerrado]

Antecedentes :

Ingeniero electrónico junior de I + D ( el único EE en la empresa ): el hardware y la codificación no son el problema. Mi mayor problema es obtener una visión general adecuada del proyecto y dónde comenzar.

Hasta ahora solo he realizado proyectos de software menores (menos de 500 líneas de código), pero no puedo imaginarme haciendo proyectos más grandes sin perder la visión general de la funcionalidad o la falta de funcionalidad.

¿Cómo estructura mejor / qué herramientas utiliza para estructurar grandes sistemas de software integrados?

Lo que estoy haciendo actualmente :

Por lo general, empiezo esbozando la funcionalidad del proyecto. Podría ser uno a muchos diagramas de flujo en capas o diagramas relacionados (diagramas de bloques, etc.) y hacer una investigación de los componentes / chips. Luego paso directamente a la codificación (supongo que falla rápidamente) mientras hago referencia a las hojas de datos / Internet, codificando una funcionalidad a la vez y probándola con datos ficticios o pruebas similares. Podría estar escribiendo datos en un chip MEM, y luego, si eso funciona, podría ser un controlador SPI entre el chip principal y el chip MEM.

Qué respuesta estoy buscando :

Cualquier cosa en realidad. Resolveré lo que considero sensato. Podría ser un libro, un artículo, experiencia personal, recomendaciones, etc.

Estoy muy interesado en saber cómo las personas mayores abordan esto.

Editar

En primer lugar, ¡gracias por compartir sus años de experiencia! Todas las respuestas son muy apreciadas. Mi toma de esto es;

• Cree un documento de especificación claro y preciso.
• Crea un documento de diseño de software. (Algo que ahora agregaré) Diseñar plantillas de documentos
• Piense en los módulos lo redundante que pueda parecer. (Algo en lo que necesito concentrarme más)
• Siga un estándar de codificación para estructurar archivos de cabecera / fuente. (Nunca hice esto) Barr Group C estándar
• Concéntrese primero en crear las implementaciones de bajo nivel. (Comunicación, etc.)
• Implemente patrones de diseño siempre que sea posible / sensato. Patrones de diseño
• Configure algo para el control de revisión (Github, etc., nunca se usó tanto)
• Investigue la integración continua / implementación continua (algo nuevo con lo que me topé) Conceptos básicos de CI y CD

Hay varios aspectos que influyen en el grado de detalle que la estructuración de un proyecto necesita. Para mí, uno de los factores principales es si soy el único que codifica (lo que parece ser el caso para usted mientras escribe que es el único EE) o si hay otros involucrados. Luego está la cuestión de lo que realmente significa "grande". Por lo general, divido el proceso de diseño en los siguientes pasos:

Definición de requisitos Si obtiene la especificación de software adecuada para trabajar con mucha planificación, ya está hecho. Si solo obtiene requisitos imprecisos, lo primero que debe hacer es resolver lo que el cliente realmente quiere (a veces, en primer lugar, en realidad no lo saben). Sé que es tentador simplemente saltar directamente a la codificación, pero eso conlleva el riesgo de perder una característica importante que podría no ser obvia en primer lugar y que no se puede exprimir fácilmente en su código en algún lugar en el medio del desarrollo.

Límites del sistema y facilidad de mantenimiento En los sistemas integrados, a menudo tiene algunas interfaces del sistema, algunas externas (operador) pero también internas. Defínalos bien e intenta mantener las dependencias lo más bajas posible, esto simplificará la ingeniería continua y el mantenimiento. También comente / codifique el documento donde sea necesario, nunca se sabe quién más tendrá que trabajar con él, estará encantado de no tener que cavar en una docena de capas de código antes de saber qué hace una función.

Defina tareas verificables Especialmente si otros desarrolladores están trabajando en la misma base de código, es inevitable definir tareas claras (características) y las interfaces necesarias entre ellas. Siempre que sea posible, las características individuales deben probarse / verificarse independientemente de las demás, ahí es donde necesita las interfaces bien definidas para que pueda definir sus casos de prueba.

Una característica después de la otra A las personas les gusta el progreso, por lo que si tiene una variedad de tareas, generalmente trabajan en lo que promete más progreso. Por lo general, trato de terminar una tarea y llevarla a un estado verificado y probado antes de comenzar con la siguiente. Esto permite que otros prueben tu código y no termines olvidando algo.

Control de revisiones Durante la vida de un proyecto, a veces necesita versiones anteriores, tal vez para identificar un error introducido con alguna nueva versión o simplemente para construir un dispositivo que se comporte exactamente de la misma manera que uno que envió hace 3 años. Asegúrese de tener claras las revisiones de compilación y las etiquetas en su código. Git es definitivamente tu amigo aquí.

Humpawumpa escribió una gran respuesta ! Solo quiero complementar algunos de sus puntos, pero como es demasiado largo para ser un comentario, escribiré una respuesta por separado.

Una vez estuve en la posición de OP, no solo el EE, sino el único EE que había desarrollado MCU en una pequeña empresa.

No puedo enfatizar lo suficiente la importancia de la modularidad , incluso si usted es el único desarrollador. Es la única forma de mantenerse cuerdo a medida que el proyecto crece. Debe ser estricto al escribir módulos que manejen solo un concepto funcional cada uno, y mantener sus interfaces externas lo más mínimo posible. Los módulos de alto nivel corresponderán a los requisitos funcionales, mientras que los módulos de bajo nivel tendrán vínculos estrechos con los recursos de hardware (es decir, los controladores de dispositivos).

Pasé mucho tiempo manteniendo un diagrama de flujo de datos detallado ¹ , que mostraba exactamente cómo los diversos módulos compartían información. Algunas características tendrán requisitos muy diferentes en términos de rendimiento en tiempo real; asegúrese de saber cómo afecta el intercambio de información. El diagrama tenía límites trazados que separaban el código sin interrupción de los diversos dominios controlados por interrupción.

¹ Muy diferente de un diagrama de flujo, que se centra en el flujo de control .

Para cualquier proyecto grande, lo planifico como si hubiera varios desarrolladores involucrados, incluso si tengo la intención de hacerlo todo yo mismo.

Los motivos son simples:

1 Complejidad. Un proyecto grande siempre tendrá complejidades involucradas. Haber planeado el proyecto como si hubiera múltiples equipos involucrados significa que la complejidad ha sido considerada y documentada . La cantidad de veces que he visto problemas grandes en proyectos grandes es alta y generalmente porque algo 'se escapó de las grietas'. No olvide que también se debe considerar el montaje mecánico y no simplemente para el tamaño de la caja: ¿habrá necesidad de disipadores de calor? ¿La caja debe estar conectada a tierra por seguridad? Hay muchas preguntas solo en esta categoría.

2 requisitos. Asumir que varias personas están involucradas significa que los requisitos de nivel superior (que a menudo cuestiono ya que pueden traer complejidad y costo innecesarios) deben desglosarse en varias tareas más pequeñas requeridas y alcanzables (que podrían alimentarse a otro equipo en una organización más grande) ) en lugar de solo mirar un solo blob.

3 Particionamiento. Hay dos tipos principales de particionamiento; funcionalidad de hardware y hardware / software. El primer tipo es determinar qué bloques funcionales separados (pero comunicantes) deben estar presentes. El segundo es una compensación de hardware y software más simple (a veces), pero tenga en cuenta que simplemente trasladar más cosas al software no necesariamente solucionará un problema de hardware. Pasar más al software puede en realidad aumentar enormemente la complejidad del hardware en algunas circunstancias (más potencia de procesamiento, interfaces más complejas y más).

4 interfaces. El proceso de partición ayudará a definir interfaces internas; Las interfaces externas suelen ser parte de los requisitos generales (aunque no siempre). Existen muchas formas para que diferentes partes de un sistema cooperen, que pueden ser un protocolo de comunicaciones complejo o simplemente una señalización buena / mala.

5 Verificación. Esta es una mezcla de pruebas de bajo nivel (para hardware y controladores) y nivel de sistema. Haber realizado el proyecto en bloques bien definidos permite una verificación robusta (que puede ser por análisis o prueba real y generalmente es una mezcla de los dos; las actualizaciones de los diseños pueden usar argumentos de similitud).

6 normas. Utilizo estándares de codificación y dibujo como si fuera un equipo más grande. Utilizo los estándares de codificación del grupo Barr, ya que no son demasiado onerosos, pero evitan que haya muchas clases de errores en el código. Para la documentación de salida de PCB, sigo IPC-D-326 (que llama a IPC-D-325) ya que es un método comprobado para comunicar mi intención a los fabricantes y ensambladores de PCB. Esto puede parecer extraño, pero tener la disciplina para seguir una serie de estándares significa que la calidad es consistente.

7 Control de versiones. Utilizo el control de revisión para todas las partes del proyecto (sistema, hardware, software, mecánica, requisitos de prueba, todo). Las herramientas CAD que utilizo admiten versiones tales como todo el software y las herramientas de compilación FPGA.

He trabajado en muchos proyectos integrados (al igual que muchas personas experimentadas por aquí) y los tamaños de los equipos han variado desde 1 (yo mismo) hasta docenas (o cientos en un conjunto particular de proyectos) distribuidos en múltiples disciplinas y, a veces, en otras áreas geográficamente remotas. sitios. Usar el mismo enfoque general (que se sabe que funciona) significa que puedo tomar una tarea en particular en un relativo aislamiento y completarla y probarla a fondo como una parte independiente del proyecto más grande. También significa que puedo eliminar algunas cosas de vez en cuando si es necesario.

Hacer todas estas cosas agrega un poco de tiempo inicial, pero en última instancia es una ruta más rápida para sistemas integrados complejos.

Las otras respuestas dan muchos buenos consejos. Aquí hay dos que he encontrado más importantes en mi carrera de desarrollo integrado:

1. Convierta la mayor parte del código en módulos separados y bien definidos como sea posible.
2. Haga que los módulos se puedan probar automáticamente en la PC.

Eso es lo que necesita para realizar un desarrollo de estilo de "integración continua" en sistemas integrados. Siempre habrá una cantidad de código que está demasiado vinculada al hardware para las pruebas automáticas, pero trate de minimizarlo. Puede llegar bastante lejos utilizando datos simulados o capturas de datos del hardware real, que luego ingresa al sistema de prueba.

Para agregar a las respuestas existentes ...

Siempre empiezo de abajo hacia arriba. Por su diseño de hardware, usted sabe cuál es su E / S. Comience por crear módulos de controlador que encapsulen esa E / S, de modo que su código de alto nivel no tenga que saber demasiado sobre las cosas de bajo nivel.

Cuando construye las interfaces de bajo nivel, por supuesto, necesita un arnés de prueba. Si diseña esto para conectarlo a la PC desde el principio (tal vez con un puerto RS-232, tal vez USB, tal vez telnet a través de Ethernet), puede mantener esta interfaz de arnés de prueba en su lugar a medida que construye su aplicación. Puede seguir agregando más ganchos de arnés de prueba a medida que la aplicación toma forma, y ​​eso también le permitirá probar su código de regresión a medida que avanza.

Tiendo a pensar en cuatro preguntas. Los dos primeros pertenecen al inicio de un proyecto de sistemas, los dos siguientes al final.

1. ¿Realmente quieren el sistema? ¿El sistema resolverá el problema de los clientes, a una escala de tiempo y costo que aceptarán? Un problema común es construir sistemas que el cliente no usará.

2. ¿Podemos realmente construir ese sistema? ¿Será posible entregar el rendimiento necesario, la precisión, el uso de energía, ...?

Crear prototipos tempranos es una buena manera de responder estas dos primeras preguntas. La mitigación de riesgos es extremadamente importante en las primeras fases.

Las siguientes dos preguntas están más orientadas a las fases posteriores del proyecto:

3. estamos realmente terminados? Todo diseñado, codificado, probado, entregado

4. ¿Realmente usan el sistema?