¿Dónde comienza su diseño: código, interfaz de usuario, flujo de trabajo o lo que sea?

Question

Estaba discutiendo esto en el trabajo, y me preguntaba dónde comenzaban sus diseños las personas? Tendemos a comenzar con el diseño del código para resolver el problema que se nos presenta, pero probablemente todos seamos (o hayamos) programadores.

Me preguntaba dónde otras personas y organizaciones comienzan su diseño. ¿Comienzan resolviendo el problema como un problema de codificación, se sientan y diseñan qué UI usar, o planifican los datos o el flujo de trabajo?

Gracias

Answer 1

¿Por qué no comenzar con las pruebas de aceptación?

Una de las cosas que he estado impulsando en proyectos recientes es asegurar que el equipo de prueba se involucre mucho en el proyecto. Si no puede aceptar un criterio de aceptación con el cliente, debe formularse la pregunta: ¿son realmente necesarios algunos de los requisitos del proyecto?

Con este fin ahora estoy muy interesado en los marcos de pruebas que intentan capturar los requisitos de una manera comprobable, por ejemplo:

• easyb
• concordian
• ..

Tal vez un marco de administración de pruebas/requisitos de aceptación automática por adelantado permitiría probar más de una solución.

Answer 2

Siempre empiezo con flujo de trabajo/proceso. He descubierto que cuando comienzas modelando procesos de negocios/flujos de trabajo generalmente tiendes a obtener más información que hace que la UI sea más útil, y el código/requisitos tienden a ser más adecuados para las necesidades de los usuarios.

Las personas generalmente cometen el error de comenzar a diseñar código/UI antes de que realmente comprendan el flujo de trabajo. Dicho esto, si comprende el panorama general, puede comenzar a diseñar en cualquiera de los 3 flujos de trabajo, código, ui (y eso es en mi orden preferido).

Answer 3

Personalmente, si la aplicación tiene una IU, ahí es donde empiezo, ya que esto normalmente expulsa los procesos y flujos de trabajo.

Paper prototyping donde tiene sentido y reiterar el diseño mientras trabajo.

Si va a ser una aplicación de línea de comandos, pienso cuidadosamente sobre las opciones de línea de comandos, los valores predeterminados y los patrones de uso normales antes de comenzar a trabajar.

Answer 4

Empiezo con el diseño a partir de los requisitos. Si los requisitos requieren una IU, tendré que diseñarla como una subtarea y diseñar el motor computacional (o como se llame) como otra subtarea; esto es una especie de MVC con una clara separación entre M y V, y C proporciona el enlace entre ellos. Entonces, diseñar C se convierte en otra subtarea.

Pero rara vez tengo el lujo de diseñar cualquier cosa desde cero estos días, es mucho más probable que agregue nuevos módulos y nuevas funcionalidades a los sistemas existentes. En tales casos, la mayor parte del diseño de la interfaz de usuario ya se ha realizado, por lo que tiene mucho del diseño M.

Y he escuchado que el diseño impulsado por prueba es un movimiento popular en estos días, por lo que las pruebas pueden ser otro punto de partida para que usted considere.

Answer 5

Mi flujo de trabajo general tiende a ir a lo largo de estas líneas:

1. requisitos de captura (definir las entradas y salidas anticipadas).
2. Diseñe algo que pueda funcionar (ideas principales de estructura de programa/flujo de datos para explicar cómo obtener desde las entradas hasta las salidas en los requisitos).
3. Prototipo de algoritmos y verificación con datos reales (generalmente en Excel y/o Python para demostrar que podemos obtener desde la entrada hasta la salida).
4. Implemente una solución (codifique el resultado en C++ /. Net).
5. Pruebe a muerte/corrija cualquier error que salga a la luz (valide contra los modelos anteriores y cualquier otra prueba que parezca importante).
6. Optomise cualquier cuellos de botella o problemas de usabilidad.

Generalmente construyo soluciones de software y/o GUI incorporadas para conectarme a esos sistemas y manipularlos/mostrar datos de salida.

Answer 6

Siempre comienzo con los requisitos, luego diseño la base de datos y luego diseño la aplicación. Una aplicación diseñada antes de la base de datos es una receta para problemas. Creo que es interesante que nadie más pareciera pensar que el diseño de la base de datos era lo suficientemente importante como para mencionarlo. No es de extrañar que haya tantas aplicaciones comerciales mal diseñadas por ahí.

Answer 7

Creo que las respuestas que obtenga a esta pregunta (tal como están) reflejarán principalmente los tipos de aplicaciones diseñadas/creadas por las personas que escriben las respuestas. Solo por ejemplo, si está diseñando un programa que obtendrá datos de una base de datos (o de alguna fuente de todos modos), haga un masaje según sea necesario y luego coloque el resultado en otra, es probable que empiece pensando en esquemas de base de datos, flujo de datos y codificación/formato de datos (probablemente en ese orden).

Por otro lado, si estaba escribiendo un programa de escritorio típico del tipo que abre un archivo, le permite editar su contenido y luego lo guarda (ya sea una fotografía, un documento de procesamiento de texto, una hoja de cálculo o lo que sea) es probable que los esquemas de la base de datos no salten al principio de su pensamiento. Alguien que haya mirado (por ejemplo) las especificaciones para los formatos de archivo de Microsoft Office probablemente tendría espacio para argumentar que, en algunos casos, el diseño sería mejor si se hubiera pensado más en el formato, pero por lo general no será de todos modos.

Para obtener una respuesta más significativa, creo que debe alejarse un poco de simplemente "¿cuál es su enfoque para resolver el problema?" a algo más como: "¿Cuál es la relación entre el tipo de problema y su enfoque para resolverlo?" De lo contrario, la mayor parte de lo que obtienes suele ser poco más que una afirmación indirecta sobre los tipos de problemas en los que ha trabajado esa persona.

Answer 8

Comienzo con el flujo de trabajo y los requisitos funcionales. Lo hago trabajando independientemente de la IU (generalmente con herramientas y scripts de línea de comandos), casi siempre con tres marcos de prueba (prueba de funcionamiento/unidad completa, comprobación de estado rápida "en funcionamiento" y prueba de esfuerzo de rendimiento). El último paso es la interfaz de usuario.

Answer 9

Empiezo con datos brutos. Ni siquiera con estructuras de datos, pero con enteros, flotantes, matrices de cadenas, matrices de enteros, etc. No hay diagramas uml o requisitos de usuario, ni jerarquía de clases ni herencia, ni interfaces de clases o funciones, ni flujos de trabajo ni procesos. Solo un algoritmo que produce un único conjunto de datos.

Answer 10

Tengo poca experiencia en programación y diseño, pero lo que sí tengo es principalmente la interfaz con las bases de datos, así que ahí es donde comienzo. Cuando me dan un problema, me siento durante una hora y dibujo el esquema de la base de datos, lo creo, luego agrego mis SP y vistas.

A continuación, escriba las consultas y los formularios, el HTML real, y el JS y CSS que lo hace parecer muy bonito (o no, que generalmente es el caso con mis "diseños").

Entonces, en el modelo MVC, supongo que es M primero, luego V? No tengo mucha experiencia con MVC.

¿Es esta una forma relativamente natural?