Cuando estoy trabajando en un proyecto, a veces primero diseño la GUI y luego escribo el código de fondo para que funcione, pero otras veces hago lo contrario y hago la GUI una vez que tengo el sistema funcionando. ¿Cómo se elije qué camino tomar para codificar y hay algún tipo particular de proyecto o circunstancia que lo respalde de alguna manera?¿Cuándo se diseña primero la GUI y el código de back-end más adelante, o viceversa?
Necesita crear algo que permita que sus probadores comiencen inmediatamente. Intenta pensar desde esa perspectiva.
Si están trabajando en la prueba de IU manual, denles un caparazón de interfaz de usuario con talones para toda la funcionalidad. Si hay una interfaz para probar, asegúrese de que funciona (incluso si devuelve datos ficticios) para que puedan comenzar a trabajar con ella, etc.
La mayoría de las veces es la IU. Podrías mostrarlo a tus usuarios y obtener retroalimentación inmediata que es realmente útil.
Creo que escribir la GUI primero y mostrar un prototipo rápido al usuario final ayuda a compartir la misma visión del producto final. En mi humilde opinión, considero que el código del lado del servidor no depende del código GUI.
A menudo prefiero comenzar con el código de back-end cuando el proyecto es "intensivo en datos" (crear, leer, actualizar y eliminar elementos, mostrar listas de datos).
GUI primero al desarrollar prototipos rápidos.
Supongo que esto depende del tipo de proyecto, y sí, soy consciente de que no es realmente una respuesta ya que todos lo hacen. Pero por lo general, puede visualizar cómo la parte delantera también quiere mirar desde el fondo.
Siempre estaría atento a la parte delantera, ya que al final del día esa parte será visible. Además, por lo general, ayuda a tener una idea de lo que se espera al visualizar, incluso si en forma de bloque o por correo postal se observa lo que desea ver en cuanto a lo que está codificando realmente.
Por supuesto, siempre es útil si es para un cliente y le dan los visuales antes de la mano :) De esta manera, siempre y cuando coincida con las imágenes todavía puede ir a la ciudad con diversión back-end no visual.
Realmente van de la mano. No puede diseñar su interfaz de usuario sin tener al menos un diseño básico del back-end para las funciones que cubrirá la interfaz de usuario. Y se agrega una nueva característica de back-end, parte del diseño consiste en descubrir cómo se expone esa función al usuario y cómo se adapta al flujo de trabajo existente.
Btw, realmente no me gusta la interfaz de usuario rápida y sucia "solo para darles a los evaluadores acceso a la función". Una vez que construya la interfaz de usuario, rara vez tendrá tiempo más tarde en el proyecto para reconstruirla desde cero (suponiendo que se trata de un proyecto en un horario :-)). Si está construyendo una interfaz de usuario, compila el píxel perfecto, de la manera en que le gustaría que se vea cuando se envíe al cliente.
De lo contrario, terminas con algo así como this monstrosity. :-)
Por cierto, si necesita construir un prototipo de UI para las pruebas de usabilidad, asegúrese de que esté construido con algo que no se puede integrar en el código de producción. Por ejemplo, construya el prototipo en Flash si está escribiendo código C++/C#/Java.
Ni, ni. Por lo general, dividimos el proyecto en tareas. Algunas tareas son parte de la construcción de la interfaz de usuario solicitada y algunas son parte de la implementación de la funcionalidad necesaria detrás de ella.Diferentes personas trabajan en diferentes tareas, por lo tanto, parte del equipo está haciendo la interfaz de usuario y otra parte está implementando funcionalidades detrás de ella. Entonces trabajamos en paralelo tanto en la interfaz de usuario como en la funcionalidad.
Solo es importante realizar las tareas en el orden correcto. Es inútil si tenemos la funcionalidad lista, pero la interfaz de usuario para usarla demorará otras dos semanas. También es inútil tener la interfaz de usuario para algo preparado, pero no funcionará durante otras dos semanas, ya que falta la funcionalidad de back-end.
Es por eso que tratamos de especificar pequeños hitos. Nadie comienza a trabajar en otro hito hasta que todas sus tareas del actual estén terminadas. Un hito siempre agrupa la funcionalidad frontend y back-end. Entonces, si se ha alcanzado un hito, la interfaz para cada funcionalidad implementada debe estar lista y cada funcionalidad de back-end implementada debe tener una interfaz para probarla.
Sin embargo, en cierto sentido puede decir que primero hacemos el código de back-end y luego la IU, ya que decir un hito necesita ofrecer una interfaz de usuario para probar la funcionalidad, no significa que esta es la IU final que enviaremos. Por lo general, cerca del final, cuando casi toda la funcionalidad de back-end está lista y probada, a menudo hacemos una revisión de UI. Esto se debe a que la interfaz de usuario para las pruebas debe estar lista para un hito, pero puede no ser siempre agradable o la interfaz de usuario que finalmente enviaremos. A menudo, la interfaz de usuario ralentizaría todo el proyecto (nuestras aplicaciones suelen ser muy intensivas en UI, ya que no nos gusta producir aplicaciones con interfaces de usuario estándar aburridas, queremos interfaces de usuario bonitas que te hagan decir "¡Guau, eso se ve increíble!") , por lo tanto, a menudo necesitamos implementar una UI intermedia para tener una IU lista para el hito y para la prueba. Con más frecuencia que menos, modernizamos la interfaz de usuario como último paso antes de la publicación. Como ya tenemos UI para todo, no es gran cosa si no podemos modernizar algunas partes (debido a limitaciones de tiempo), después de todo, hay una interfaz de usuario, simplemente no es bonita, pero está funcionando y probada. Así que trataremos de renovar tanto como sea posible dentro del marco de tiempo dado, sabiendo todo el tiempo que si debemos detener el proceso de renovación mañana, tenemos una aplicación totalmente funcional y con capacidad de desplazamiento. La actualización de la interfaz de usuario solo está puliendo, es bueno tenerla, pero también podría lanzarla sin ella.
Hay dos preguntas para hacer para determinar esto: a) cuál es el más importante b) cuál es el más difícil.
Si está escribiendo una solicitud de procesamiento de pedidos, es evidente que su éxito va a depender más de la interfaz de usuario que del código de back-end. Entonces probablemente debas diseñarlo primero, obtener un cierto nivel de aprobación por parte de tus clientes, y luego diseñar el backend para que coincida con él.
También se debe decir que el diseño no se termina hasta que ambos estén diseñados, y lo que haga en segundo lugar puede implicar el rediseño de lo que haga primero.
+1 para el comentario sobre tener que volver a hacer lo que hagas primero. Pasando por ese proceso en este momento. –
Mi manera es:
Primero debe comenzar por recopilar los requisitos del usuario o del cliente y luego analizarlos. después de eso, se puede seguir el siguiente modelo general del proceso de diseño:
Por lo tanto, hacer un diseño profesional debe seguir estos tres capas en que declaró en el libro Ingeniería de Software de Ian Sommerville.
En resumen, y si acortamos la respuesta, podemos decir que la mejor respuesta está trabajando en la interfaz gráfica de usuario y en el diseño de la base de datos casi al mismo tiempo. Y después de hacer muchos cambios en ambos; finalmente, ambos diseños se producirán casi al mismo tiempo.
Tu punto final es brillante, ojalá hubiera pensado en ello. –