(Círculo de LabVIEW: Parte 4 de 6)
Este es Círculo de LabVIEW: Desarrollo, la cuarta de una serie de entradas de blog que describen las diferentes etapas del ciclo de vida del proyecto LabVIEW desde la idea hasta el mercado. Aunque leerlos en orden ayudará a entender el panorama general, cada entrada del blog es independiente con una pequeña sección sobre el "RT Installer", una especie de producto de muestra utilizado en esta serie.
En el paso anterior, delimitamos el alcance y definimos una serie de requisitos que nos sirvieron para planificar el desarrollo y comunicar los avances al cliente.
El proceso de desarrollo suele estar en función de cómo se validará el proyecto o producto una vez verificada su funcionalidad. En el caso de los productos, creemos que la creación iterativa de funcionalidades que puedan ser experimentadas por el cliente facilita la comunicación del estado del proyecto. El desarrollo se inicia con menos actualizaciones hasta que se ha completado lo suficiente como para ofrecer actualizaciones periódicas.
El proceso de desarrollo también está en función del documento de requisitos. Aunque un documento de requisitos no recogerá todo lo que hay que implementar, a menudo deducirá lo que hay que programar y dónde. Cuando diseñamos documentos de requisitos, lo hacemos con la idea de que nos permitan verificar objetivamente la funcionalidad, pero sin constreñir innecesariamente el proceso de desarrollo. Un documento de requisitos puede utilizarse para crear hitos de desarrollo.
Los hitos de desarrollo pueden utilizarse para programar y organizar qué funcionalidad debe implementarse, así como cuándo proporcionar hitos para la facturación. A menudo, en los proyectos de licitación fija, para un cliente es difícil invertir y no tener nada que mostrar hasta el final.Con los hitos, los desarrolladores pueden completar la funcionalidad hacia ese hito, presentarlo al cliente mientras se verifica la funcionalidad y, tras la aceptación, facturar. Cuando se paga la factura, podemos proporcionar el código fuente o una aplicación que demuestre la funcionalidad.
Como desarrolladores, sabemos que la interfaz hace la aplicación. Una interfaz atractiva o de aspecto "acabado" comunicará que el proyecto está casi terminado. Intentamos encontrar un equilibrio entre una interfaz funcional y una interfaz terminada. A menudo, completamos una interfaz sólo lo suficiente para poder demostrar la funcionalidad subyacente. Esto tiene dos propósitos: (1) comunica que la aplicación es todavía un trabajo en curso; y (2) da al cliente la oportunidad de desarrollar opiniones sobre la interfaz.
Al igual que en la fase de concepción, es difícil saber lo que se quiere hasta que hay algo que ver. Esperar hasta el final para terminar la interfaz permite un eficiente ir y venir para acercarla a la idea tanto como sea razonable. Durante el desarrollo del "RT Installer", nuestra interfaz sufrió un par de cambios.
La interfaz inicial era muy funcional, y nos dio la oportunidad de definir la funcionalidad que queríamos y comprobar que funcionaba como esperábamos.
A medida que íbamos utilizando la aplicación, se nos ocurrían distintas formas de organizar la ubicación de las cosas y de racionalizar las funciones básicas.
Más o menos: Versión inicial
Acerca de: Versión final
Configuración: Versión inicial
Configuración: Versión Final
FPGA: Versión inicial
FPGA: Versión final
Navegación: Versión inicial
Navegación: Versión final
Red: Versión inicial
Red: Versión final
Versión inicial (flujo)
Versión final (Flujo )
Hemos incluido un vídeo que muestra el flujo de trabajo inicial del "RT Installer" antes y después de la v0.9.7. También hemos incluido notas tomadas durante en un intento de proporcionar más información sobre el proceso de desarrollo aquí.
Haga clic aquí para ver las notas.
