En la fase de definición previa, describimos el sistema con grandes bloques funcionales. Solo hicimos algunos prototipos de aquellas partes más complejas o desconocidas (pruebas de concepto, o proofs of concept (PoC)) para comprobar la viabilidad del proyecto.
En esta fase se trata de entrar en el detalle. Cada uno de los bloques de hardware y software que se definieron previamente tienen que ser analizados y descritos.
Esta es la fase más importante del proyecto, se debe dedicar hasta el 50 % del tiempo total del proyecto. Si se hace correctamente, con el suficiente rigor, se conseguirá mantener controlado el proyecto y tendremos éxito en cuanto al plazo, coste, y cumpliendo los requerimientos de alcance del proyecto.
En cuanto al hardware, en esta fase, a partir de los grandes bloques descritos en la fase de definición, iremos bajando de nivel, desglosándolos en sub-bloques hasta llegar al nivel del esquemático. Utilizaremos herramientas de simulación (PSPICE, Webench, ...) cuando creamos que necesitemos validar el funcionamiento de un circuito, y mantendremos una exhaustiva documentación de todos las simulaciones. También mantendremos una documentación de los criterios que hemos seguido en la selección de los componentes. Es importante mantener un registro de los criterios de las decisiones de diseño, esa información nos puede ser muy útil para futuros proyectos.
En cuanto al software, en esta frase se trata de conseguir la definición en diagramas de bloque del flujo del programa. Hay que tomar decisiones sobre la gestión de las interrupciones, determinar las tareas críticas,...
Durante esta fase el desarrollo del software tiene que ir en paralelo con el desarrollo del hardware. Hay empresas en las que se crean dos grupos de trabajo muy diferenciados entre los desarrolladores del hardware y del firmware. Si no se aseguran canales fluidos de comunicación entre los dos equipos, los problemas de malos entendidos, falta de sincronización, ... no tardan en aparecer.
Esta sigue siendo una fase frustrante para el ingeniero inquieto que prefiere programar, o hackear el hardware, antes que documentar. Creo que hay que hacer una llamada a la profesional, o al gusto por hacer las cosas bien hechas, para evitar caer en la tentación de ir por libre. No se trata de hacer "algo" que funcione, se trata de hacer algo que funcione en el tiempo, coste establecidos, y con la calidad requerida, y para conseguir eso, hay que meditar y documentar previamente en las posibles opciones que se disponen. Desgraciadamente, esto es algo que a menudo no se comprende, y que tiene que ver mucho con la productividad de un departamento de diseño.
Como resultado de esta fase, se tiene que disponer de los diagramas de arquitectura y diagramas de flujo del software, y los esquemáticos, y listas de material, del hardware.En esta fase se trata de entrar en el detalle. Cada uno de los bloques de hardware y software que se definieron previamente tienen que ser analizados y descritos.
Esta es la fase más importante del proyecto, se debe dedicar hasta el 50 % del tiempo total del proyecto. Si se hace correctamente, con el suficiente rigor, se conseguirá mantener controlado el proyecto y tendremos éxito en cuanto al plazo, coste, y cumpliendo los requerimientos de alcance del proyecto.
En cuanto al hardware, en esta fase, a partir de los grandes bloques descritos en la fase de definición, iremos bajando de nivel, desglosándolos en sub-bloques hasta llegar al nivel del esquemático. Utilizaremos herramientas de simulación (PSPICE, Webench, ...) cuando creamos que necesitemos validar el funcionamiento de un circuito, y mantendremos una exhaustiva documentación de todos las simulaciones. También mantendremos una documentación de los criterios que hemos seguido en la selección de los componentes. Es importante mantener un registro de los criterios de las decisiones de diseño, esa información nos puede ser muy útil para futuros proyectos.
En cuanto al software, en esta frase se trata de conseguir la definición en diagramas de bloque del flujo del programa. Hay que tomar decisiones sobre la gestión de las interrupciones, determinar las tareas críticas,...
Durante esta fase el desarrollo del software tiene que ir en paralelo con el desarrollo del hardware. Hay empresas en las que se crean dos grupos de trabajo muy diferenciados entre los desarrolladores del hardware y del firmware. Si no se aseguran canales fluidos de comunicación entre los dos equipos, los problemas de malos entendidos, falta de sincronización, ... no tardan en aparecer.
Esta sigue siendo una fase frustrante para el ingeniero inquieto que prefiere programar, o hackear el hardware, antes que documentar. Creo que hay que hacer una llamada a la profesional, o al gusto por hacer las cosas bien hechas, para evitar caer en la tentación de ir por libre. No se trata de hacer "algo" que funcione, se trata de hacer algo que funcione en el tiempo, coste establecidos, y con la calidad requerida, y para conseguir eso, hay que meditar y documentar previamente en las posibles opciones que se disponen. Desgraciadamente, esto es algo que a menudo no se comprende, y que tiene que ver mucho con la productividad de un departamento de diseño.
En el próximo post hablaré de la fase de definición del test.
No hay comentarios:
Publicar un comentario